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/ProtoFrame.h

@@ -8,6 +8,13 @@
 // nothing of the shade model (docs/PROTOCOL.md).  Kept free of the shade model
 // and the web server so it can be unit tested on the PC (pio test -e native).
 
+// Who an op's reply goes to when loop() sends it: the socket client and the
+// op's id.  A client of 0 wants no reply.
+struct proto_reply_to_t {
+  uint32_t client = 0;
+  uint32_t id = 0;
+};
+
 // A frame: {"v":2,"t":<type>,"id":<id>,"d":{ ... }}.  id 0 leaves it out.
 void beginFrame(JsonFormatter &json, proto_type_t type, uint32_t id = 0);
 void endFrame(JsonFormatter &json);