fix: edit ops review findings

From the review of 7723711:
- The assembler is locked: a client closed for a full queue is closed
  by the task that was sending, loop(), whose disconnect dropped the
  buffer while async_tcp could be copying into it. A whole message is
  taken out of it, so a disconnect can't free it while it is read.
- loop() expires a message stalled for 10 s, freeing its buffer and
  telling its client, instead of holding it until another client came.
  A binary message is refused before it can touch another's buffer.
- Each edit takes only the fields its route reads; one it would ignore
  is refused by name. linkRemote's rolling code goes in under the
  route's name, so applyModelEdit is unchanged again.
- An edit refused for an id that doesn't exist replies not found
  (edit_result_t::missing). A reply that doesn't fit its buffer goes
  as an internal error, so the op still gets one.
- The TYPE table says what becomes of each op (proto_op_t), which the
  socket switches on. The reply address is one proto_reply_to_t. The
  routes and the ops start and queue an edit the same way
  (newModelEdit, submitModelEdit). The full-list texts and the offered
  remote address rule live in ModelEditor.
- e2e: the sort order test skips a list that it would renumber.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

src/ShadeController.cpp

@@ -183,7 +183,7 @@ uint32_t SomfyShadeController::getNextRemoteAddress(uint8_t id) {
     if(this->shades[i].getShadeId() != 255) used[count++] = this->shades[i].getRemoteAddress();
   for(uint8_t i = 0; i < SOMFY_MAX_GROUPS; i++)
     if(this->groups[i].getGroupId() != 255) used[count++] = this->groups[i].getRemoteAddress();
-  return freeRemoteAddress(this->startingAddress + id, used, count);
+  return offeredRemoteAddress(this->startingAddress, id, used, count);
 }
 uint8_t SomfyShadeController::getNextRoomId() {
   uint8_t ids[SOMFY_MAX_ROOMS];