Auto-seal reconcile replaces the manual commit

[thomasjonas]

What to build

Replace the manual Create link commit with an automatic, repeatable seal. The share link is generated as a consequence of the well settling, and stays current as the sender renames or adds/removes files. This slice keeps the existing page layout (the link may still surface via the current TransferLink); the full well restructure is a later slice.

All manifest writes flow through one debounced, serialized reconcile (never concurrent PUTs) that recomputes from live client state on each run: members = fully-uploaded files, and sealed = (nothing queued/uploading) && members.length > 0. Emptying the well deletes the bundle (link reverts to /gone).

The non-negotiable invariant from docs/adr/0002-sealed-manifest-lifecycle.md: the manifest is never sealed: true while any upload is in flight. Sealing must be a reconcile that reads live state at write time — NOT an eager "write sealed on file-done", which races a concurrent add and can publish a sealed manifest missing the new file. The worst observable state must be a brief in-progress page, never a premature or partial download.

Acceptance criteria

• The manual "Create link" button is removed; the link is produced automatically once the well settles
• A single debounced, serialized reconcile is the only code path that writes the manifest
• Reconcile recomputes members and sealed from live state each run; a trailing reconcile fires when the last in-flight upload settles so the final write reflects settled truth
• Adding a file to an already-sealed transfer un-seals it (writes sealed:false), then re-seals once it settles again
• Removing the last file (emptying the well) deletes the bundle server-side
• Test/verify the race: rapidly adding a file just as another finishes never yields a sealed:true manifest while an upload is in flight
• Renaming re-seals without a spurious dark window when no upload is in flight

Blocked by

• Sealed manifest contract, end-to-end #1