#3213 Accept early signals through swamp serve

Problem

Part 5 of 6 of keyed signal waits. swamp-club#3212 holds an early signal for the local command. Through swamp serve the by-key forms of swamp-club#3211 still refuse a signal when no wait is open, so a device that signals over the network cannot be early. And a run whose wait missed a pending signal as it opened stays suspended under serve until something looks.

Proposal

• Serve's by-key delivery stores a pending signal when no wait is open and the step sets acceptEarly. Authorization is unchanged and still comes first: signal on the named workflow, before anything is read.
• A caller granted only signal gets the receipt, in the same reply whether a wait took the signal or the signal is held. The reply then does not say whether a run is waiting. A caller who may also read the workflow is told that the signal is pending and until when.
• Continuation. When the instance that stored a pending signal finds the key claimed just afterwards, it continues that run as it does after any signal (continueAfterSignal in src/serve/signal_delivery.ts). Otherwise the continuation sweep (src/serve/continuation_sweep_service.ts) finds it: decideContinuation counts a wait with an applicable pending signal as settled, through the reader rule of swamp-club#3212.
• A step that takes a pending signal as it opens does not suspend the run, so a client attached to the run stream sees the step succeed with no suspended event for it.
• Bounds. A key holds one pending signal and only declared keys take one, so what serve stores is bounded by the workflow definitions. The existing rate limits and the 16 KiB payload cap apply.
• Audit events for a signal stored as pending and for a wait taking one, each with the receipt ID and the key. The payload is never logged or audited.
• Any instance may store a pending signal and any instance may take one; the write-once records decide, as they do for outcomes.

Open decisions

1. The HTTP status for a signal that is held. Using a different status from a delivered one would tell a signal-only caller whether a run is waiting; one status for both is proposed.
2. The HTTP status and WebSocket error for a second early signal while one is pending.

Acceptance criteria

• A credential granted only signal sends by key before the run reaches its wait and gets a receipt. The run, on reaching the wait, takes the signal and goes on without suspending.
• A signal stored at the moment a wait opens on another instance: the run continues within the sweep interval at the latest, with no client action.
• A second early signal while one is pending is refused.
• A keyed wait without acceptEarly answers as in swamp-club#3211.
• The audit events are written and carry no payload.

Tests

• Additions to integration/serve_signal_test.ts for both transports: a held signal taken by a later wait, the reply split between a signal-only caller and a reader, the second early signal.
• An integration test with two instances over one store and ordered creates for the signal that lands as a wait opens.

Depends on

swamp-club#3211 and swamp-club#3212.

References

swamp-club#3094, swamp-club#3108, swamp-club#3109, the Signal paragraphs of design/primitives/serve.md, the Continuation paragraphs of design/primitives/workflows.md.