bregctl check does not report a review.policyId that no bound Casework review kind resolves

[jeremi]

Problem

A BReg change request type can declare review.policyId with authority: casework. If the bound
Casework project declares no review kind with that id, nothing in the toolchain reports it.
bregctl check passes.

The configuration reads as though decisions route to Casework. They do not: the decision path is
unbound. A typo in a policy id produces exactly this state, and the only visible symptom is at
runtime.

Why this one matters more than the usual authoring slip

Every other authoring mistake of this shape fails loudly somewhere. This one produces a project
that looks correct in review, passes check, and silently has no decision path behind its
approval step. For a registry where the approval step is the control, that is the highest
consequence silent failure we found while reading real projects through the CLIs.

Request

When a Casework project is bound, treat an unresolvable review.policyId as a check error and
name both ids (the policyId as declared, and the fact that no reviewKinds[].id matches).

Note on placement

The binding is only knowable when both projects are in hand, so bregctl check may not be the
right home. caseworkctl sees the pair after source add --apply. We have no strong view on
which side owns it, only that today neither does.

Found against origin/main at ec0573f3d, binaries 0.32.0-dev, reading the
professional-licences starter bound to the professional-review Casework example.