rstack dev check: validate bindings with the products' own readers #2642

Problem

rstack dev check validates the plan's BReg and Casework bindings by re-stating the rules the products apply when they read the binding config the runner writes (reviewAuthorities.* for BReg, contextProviders.* for Casework). Twice in the review of #2637 the restatement was looser than the product: bound audiences that were not resource URIs, and grant scopes outside the OAuth client's limits. Each time the plan passed check, start provisioned databases and packages, and the product then refused its own config.

Both checks now call the shared predicates the products call (valid_resource_uri, validate_requested_scopes). A rule a product adds outside those predicates can still drift.

Proposal

During check, render each binding fragment with the same code start uses (RuntimeBindings::configure) and validate it with the product's own reader:

• BReg: the review-authority parse in registry_breg::runtime_config (bregctl already depends on registry-breg with the runtime feature).
• Casework: the BregBinding checks in registry-casework-breg, which today run only while building the provider. This needs an offline entry point that skips secret resolution and the context export, and a dependency from the runner on that crate.

Report a refusal at the plan field that produced the value, not at the generated fragment.

Also confirm that the Casework statusProfile the runner writes (the BReg grant's profile) is checked against the paired context export's service-status profile before start. That cross-project rule was not verified during the #2637 review.

Acceptance

• A plan whose binding config a product would refuse fails rstack dev check with a plan pointer, before start provisions anything.
• A unit test per product proves a rule added only to the product reader is caught without a runner change.
• The restated binding checks in project_dev/bindings.rs that the product readers cover are removed.