Validate retained review producer bindings at startup

Start in crates/registry-casework/src/runtime.rs at serve_from_path and trace validate_retained_completion_destinations, then read producer_for_actor in crates/registry-casework/src/review.rs. Inspect how non-erased pending and retained review requests store producer identities. Done means startup reports the incompatible producer identity and refuses to start when it no longer resolves against the loaded package; otherwise startup continues normally.

An automated review of #1189 flagged that Casework runtime startup does not validate review producer identity against retained requests. serve_from_path in crates/registry-casework/src/runtime.rs (around line 356) calls validate_retained_completion_destinations, which only checks that each retained casework_review_completion_outbox.destination_id is present in the configured completion destinations; it never checks whether the package's reviewProducers still match the producers recorded on pending or retained review requests. producer_for_actor in crates/registry-casework/src/review.rs resolves a producer only by exact (profile, issuer, subject) match against the currently loaded package, and stored requests are keyed by the original producer_id/producer_issuer/producer_subject.

Failure scenario: an operator updates the policy package to remove a review producer, or changes its id, issuer, or subject, while that producer still owns pending or retained review requests. Startup succeeds because only completion destinations are validated. After the update, the producer can no longer be resolved by producer_for_actor, so it can no longer create, poll, or cancel requests, or consume its result feed, for anything submitted under the old identity.

Suggested fix:

• At startup, additionally validate that every producer identity referenced by non-erased review requests still resolves against the loaded package's reviewProducers.
• Refuse to start with a named diagnostic identifying the incompatible producer when it does not.

Filed from the review of #1189; not merge-blocking.