Resolves #16303

Refs #16300

Related: #16246

Related: #16253

A Shape-B row missing its signingKey no longer fails silently forever. The refusal is now counted as a delivery failure, so the existing degrade engages and the row stops reading active while the seat is deaf.

Evidence: L2 (unit, exact head, RED re-derived by reverting the source with the specs held) → L2 required (the behaviour is fully reachable in unit). Residual: none.

Close-target: #16303, a leaf split out of #16300 so this PR resolves something it actually finishes. #16300 stays open for the repair path (rotate-key).

The split was prompted by the PR body lint, and the lint is right on principle: a PR carrying only Refs has no close-target, which is orphan work at the graph level. The honest response is a ticket the work genuinely closes — not a Resolves pointed at something this PR does not finish. Detectability and repair are separable in fact: this half needs no design decision, and it is worth landing ahead of the other because a repair can only be triggered by someone who knows they need it.

The defect

@neo-opus-grace found and characterised this. Her diagnosis, verified at source before I touched anything:

// WebhookDeliveryService.deliver(), before
if (!signingKey) {
    logger.error(`… refusing unsigned Shape-B delivery.`);
    return 'skipped';                                    // ← returns here
}
…
await this._recordConsecutiveFailure(subscription.id);   // ← :155, never reached

The precision worth keeping, and the reason this is the most silent of the four wake failure modes: #16246/#16253 are not failing. They are downstream of an attempt that does not happen. Anyone debugging this by instrumenting the degrade path finds it healthy and concludes the subsystem is fine.

No attempt recorded ⇒ no failure counted ⇒ no threshold met ⇒ no degrade. The row then reads active on every surface — list, checkSunsetted, heartbeat inclusion — while the seat receives nothing.

Deltas

1. The missing-url branch gets the same fix. Grace's ticket names signingKey; url is the identical shape three lines up, with the same return 'skipped' and the same silence. Fixing one and leaving its twin is how the next incident gets filed.

2. Counted through the existing threshold, not degraded on first sight. A missing key is permanent, not transient, so immediate degrade is arguable and I considered it. Rejected: the existing machinery already owns persistence, restart survival, and #16253's resume path, and a second degrade trigger with its own semantics would be a second thing to keep correct. The cost is up to two more silent wakes before the state becomes visible — bounded and self-clearing, unlike forever. Stated as a trade rather than a free win.

3. 'failed' rather than 'skipped', verified inert before changing it. 'skipped' means inapplicable target; a keyless row is a delivery that failed. Before changing a return value I checked every consumer of the outcome string: only CoalescingEngineService.mjs:401 branches on it, and only on outcome === 'delivered'. skipped and failed share every downstream path, so this is semantic honesty with no behavioural reach.

Contract Ledger

No public API change. The degrade mechanism, its threshold, and the resume path are untouched.

Test Evidence

npx playwright test -c test/playwright/playwright.config.unit.mjs WebhookDelivery CoalescingEngine
  51 passed

RED re-derived at this head — source reverted to return 'skipped' with the specs held:

2 failed   19 passed

Two failures, one per branch, so the specs are independent falsifiers rather than one assertion covering both. Genuine behavioural difference, not an absent-capability failure.

The existing spec was pinning the defect. refuses unsigned Shape-B delivery without issuing a request asserted toBe('skipped') — its name states the real invariant (refuse, issue no request) while the string pinned the implementation detail that was the bug. It now asserts the invariant plus the degrade, in the same shape as the 5xx spec above it so the two paths are directly comparable:

expect(await deliver(…)).toBe('failed');  expect(updatedNodes.length).toBe(0);  // 1st
expect(await deliver(…)).toBe('failed');  expect(updatedNodes.length).toBe(0);  // 2nd
expect(await deliver(…)).toBe('failed');  expect(updatedNodes.length).toBe(1);  // 3rd
expect(updatedNodes[0].properties.status).toBe('degraded');
expect(fetchCalls).toHaveLength(0);       // original invariant, unchanged

The fetchCalls assertion is retained deliberately: it is what the spec was actually protecting, and it must survive a change that makes the refusal louder.

Post-Merge Validation

• A keyless row degrades within three wake events instead of never. Only observable on a plane with such a row; @neo-opus-grace's seat is the known instance.

Evolution

Grace's ticket did the hard half — she confirmed this in production rather than inferring it, and recorded two traps that would each have closed it as a non-issue (list does not redact, so an absent key in the output is an absent key; and "just re-subscribe" is the documented instinct that does not work, while testing it on a fresh row shows a key minted and looks like proof the path is fine).

What I would defend: shipping this half before the repair path. It needs no design decision, and it changes the failure from undetectable to detectable — which is worth more than it looks, because the repair can only be triggered by someone who knows they need it.

What I am least sure of: the three-event delay. If a seat receives wakes rarely, "three events" can be hours. An argument for immediate degrade on a permanent defect is available and I did not take it; if a reviewer prefers it, the counter-argument is a second trigger to keep correct, and I would want that traded explicitly rather than assumed.

Authored by Ada (Claude Opus 5, Claude Code). Session 56105163-6e66-44b6-8c6f-9e81bc1be08c.