Casework: emit a signed event when a work item changes state

## What Happened

Registry Casework receives a signed event from Registry BReg when a change request moves (`POST /events/sources/{sourceId}`), treats it as an invalidation hint, and reconciles with an authoritative read. Nothing flows the other way. When a work item changes state (offered, claimed, released, decided, applied, superseded) no event leaves Casework; the only outbox is the hash-chained audit journal.

Every programmatic consumer therefore polls:

- the public tutorial "Review BReg changes in Casework" loops on the inbox with a two second sleep and explains why;
- the OpenFn adaptor (`registrystack/openfn-language-registry-stack`, `packages/registry-casework`) ships a `pollCaseworkResults` job driven by an external schedule;
- a downstream acceptance harness polls `listWorkItems` every 100 ms for up to 15 s.

## Expected Behavior

One outbound event type, "work item state changed", delivered with the same destination configuration and `X-Registry-Signature` v1 contract BReg already uses from `registry-platform-httputil` (`EventDestinationRequestTemplate::event_delivery`). Payload: work item id, state, revision, source id, subject kind and id, occurrence id. No payload values, no decision text.

## Scope

- Reuse the BReg outbox and delivery worker pattern (five attempts, backoff, operator list and replay through `caseworkctl`).
- Runtime configuration binds logical destination ids to receivers exactly as `eventDestinations` does for BReg.
- No generic subscription API, no long-poll endpoint, no change-feed cursor. Webhooks are the one extension point; keep it that way.
- Document the event in `products/casework/README.md` and the public API reference, and make `caseworkctl dev` bind a loopback receiver the way `bregctl dev` does.

## Environment

0.30.0 and the `caseworkctl dev --source-project` branch.

Triage: next release after the tutorial ships. Related: #936, #1002 (dev-time delivery to an external receiver).

Inizia tracciando l’outbox BReg esistente e il worker di delivery, incluso EventDestinationRequestTemplate::event_delivery, quindi esamina la configurazione di eventDestinations e il percorso caseworkctl dev. Il lavoro è completato quando gli eventi di modifica dello stato usano il payload e il comportamento di delivery indicati, i flussi di sviluppo replay e loopback funzionano e products/casework/README.md insieme al riferimento pubblico dell’API documentano l’evento.

Scritto dal modello di indicizzazione a partire dal testo della issue.