#3214 Show wait keys and pending signals to remote clients and the dashboard

Problem

Part 6 of 6 of keyed signal waits. After swamp-club#3209 to swamp-club#3213 a wait can have a key and a key can hold a pending signal, but only the local waits listing shows the key. A run on a server prints a signal command that names the wait ID, the dashboard shows neither a key nor a pending signal, and nothing shows that a step was answered by a signal that arrived before its wait opened.

Proposal

• workflow.waits and swamp workflow waits --server carry each wait's key. Asked with an option, as includeSignalled is asked for today, the reply also lists the pending signals of the workflows the caller may read: key, workflow, receipt, when it was received and until when it is held. Without the option the reply is unchanged for existing clients.
• No new event kind goes on the run stream. A wait's key travels as a field of the suspended event's wait and of each nestedSignalWaits entry, which a released client ignores (the rule in src/serve/serializer.ts).
• workflow run, local and with --server, prints the by-key signal command when a run suspends on a keyed wait. A step that failed because its key was held names the holding run to a caller who may read it.
• workflow history get shows the key on a waiting step, and marks a step that was answered by an early signal.
• The dashboard's Approvals page shows the key and the by-key command on a wait's row and lists pending signals; run detail shows a waiting step's key (packages/dashboard/src/components/SignalWaitsPanel.tsx, packages/dashboard/src/components/StepSignalWait.tsx, packages/dashboard/src/client/signal_wait_state.ts).
• Redaction follows nested waits: a key and a pending signal are named only to a caller who may read the workflow they belong to.
• The swamp skill's workflow and serve references and the design docs describe keys and pending signals from end to end.

Open decisions

1. Whether the listing shows pending signals by default or only on request.
2. Whether the dashboard should send a signal. It cannot today, and this issue does not add it.

Acceptance criteria

• A run on a server that suspends on a keyed wait prints a signal command using the workflow and key, with the --server it was given.
• swamp workflow waits --server shows keys, and with the option shows pending signals, for the workflows the caller may read and no others.
• The dashboard shows a keyed wait with its key and command, and a pending signal with its age limit.
• A client that predates these fields parses every reply and event as before.

Tests

• Unit tests for the listing and the renderers; component tests for the two dashboard components, rendered to static markup under deno test as the existing ones are.
• src/serve/serializer_test.ts still pins the event kinds that are sent.
• An integration test for the redaction of a nested run's keyed wait.

Depends on

swamp-club#3211 for the key parts and swamp-club#3213 for the pending-signal parts.

References

swamp-club#3110, the "Signal waits in a run stream" paragraph of design/primitives/serve.md, the Listing paragraphs of the Wait for Signal section in design/primitives/workflows.md.