fleet ydoc entries do not converge across processes/hosts; they appear session-scoped and not persisted

[Regis-RCR]

Summary

fleet_ydoc_append / fleet_ydoc_read behave like a per-MCP-session in-memory
document, not a shared or persistent one. An entry appended from one MCP session
is invisible from another session, from another MCP process, and after an engine
restart. Intents, leases, and episodes do the opposite: they are shared across
clients of the same engine, and they survive a restart. The ydoc layer is the
odd one out.

Environment

• memtrace 0.6.11
• macOS (Apple Silicon)
• One MemDB engine, two MCP clients in remote mode against it (or one client and
  two sessions)

Steps to reproduce

1. Start a MemDB engine. Connect client A and client B (both remote mode against
   the same engine endpoint).
2. From A: fleet_ydoc_append(repo_id, symbol_id: "sym_x", agent_id: "A", body: "...", kind: "intent").
   A valid entry_id is returned.
3. From B: fleet_ydoc_read(repo_id, symbol_id: "sym_x") returns count: 0,
   entries: []. B does not see A's entry.
4. Open a fresh session on A and read sym_x: also count: 0. A does not read
   back its own prior-session entry.
5. Restart the engine. Read any symbol_id that had entries before: count: 0.
   (Leases / intents / episodes reappear via hydration; ydoc entries do not.)

Observed

ydoc entries are visible only within the single MCP session that appended them.
They do not propagate to other sessions, other processes, or other hosts sharing
the engine, and they are not persisted across a restart.

Expected

A shared document surface is expected to converge across clients that share
the backend, and to persist. Today the ydoc layer is effectively session-local
scratch memory.

Why it matters

In a multi-agent or multi-host setup, intents, leases, and episodes coordinate
through the shared backend. The ydoc layer does not, so cross-host convergence of
the ydoc never happens. A coordination primitive that only sees its own session
cannot coordinate anything.

Note

If ydoc is meant to be session-local in this build, a line documenting that
scope would set the right expectation. Otherwise, routing it through the same
backend the other primitives use should make it converge.

[blocksorg]

Mention Blocks like a regular teammate with your question or request:

@blocks can you add technical details to this issue?
@blocks make the following changes ...
@blocks create an issue from what was mentioned in the following comment ...
@blocks explain the following code ...
@blocks are there any security or performance concerns?

Run @blocks /help for more information.

Workspace settings | Disable this message

[Alex793x]

Confirmed: the ydoc layer was in-process memory with no persistence at all — the odd one out, exactly as you described. Fixed in v0.6.17: thread entries now persist through the same shared backend as intents/leases/episodes, hydrate at boot and on the periodic sync, and reads converge with other sessions' appends on demand. Your three repro steps (cross-session read, fresh-session read-back, engine restart) are covered by a regression test in the two-session shape.

One honest scope note: entries converge through the shared store (deduped, ULID-ordered) rather than via CRDT update exchange — for the append-only thread log that's semantically equivalent today. True y-sync update propagation is part of the planned fleet round.