frontend: define recovery for stalled column mutation lanes

[Chris0Jeky]

Column writes now serialize per board in PR #3315. That preserves server intent order, but makes one unbounded response hold later work on that board.

Observed source path: runColumnMutation awaits the full predecessor promise, including reconcileReopenedBoard's getColumns call. columnsApi uses no timeout on those reads or writes. If an already-started write succeeds after leave/reopen and its recovery GET never settles, later writes stay queued; logout/re-entry retains the private queue. Reload currently clears the lane. Independent review classified this MEDIUM availability risk, with no confirmed security or data-loss path.

Acceptance:

• Bound recovery-read lifetime and provide an explicit user-visible recovery for a stalled column lane.
• Distinguish a read timeout from a write whose server outcome is unknown. Do not assume aborting transport reverses an accepted write or release later writes in a way that breaks ordering.
• Deferred-response tests prove later work can recover according to the documented policy and stale responses cannot overwrite a newer visit/session.
• Preserve existing per-board intent ordering and independence between boards.

Source: independent review of e3c742f against a79118f. This is a nonblocking follow-up to #3314, separate from #3305 shared-loading arbitration.