BReg change requests: submit admits submitter targets twice, and admission blanks the target context instead of restoring it

Found in the review of PR #929 (2026-09-09). Line references are as of that branch; re-resolve after it merges. Both points are in `crates/registry-breg/src/mutation/request.rs`.

**1. A submit admits its submitter targets twice.** The generic request-action path admits them for Submit and Revise (lines 600-612), and the submit routine admits them again for the same claims (lines 1237-1255). Each call clears the change-request target context, reinstalls the target row boundaries, takes `LOCK TABLE ... IN SHARE MODE` on every target table and re-reads every target row (`admit_submitter_targets`, from line 2201). The second pass is idempotent, so the answer is right; the cost is two rounds of locks and one more place to reason about. Consolidate to one admission per mutation, or state in the code why the submit routine needs its own.

**2. `admit_submitter_targets` clears the target context instead of restoring it.** It sets `registry.change_request_target_context` to the empty string before its loop (lines 2243-2250) and leaves it empty on return. Today that is harmless: admission always runs before any target context is installed, and the coordinator uses the same clear-to-empty as "restore the ordinary request context" (lines 1042-1050). The hazard is latent. An admission that ever runs after `install_change_request_target_context` (`crates/registry-breg/src/postgres/context.rs:2213`) would silently blank a context a later statement depends on, and no test would notice, because clearing is indistinguishable from the ordinary state. Either save and restore the prior value, or assert on entry that the setting is empty so a future reordering fails loudly.

Neither point changes an authorization answer today, which is why they are a follow-up rather than a fix in #929.

Security-sensitive area (change-request admission and the settings the generated RLS policies read); needs explicit review notes when implemented.

Start in crates/registry-breg/src/mutation/request.rs at the generic Submit/Revise path, the submit routine, and admit_submitter_targets; then read the context handling in crates/registry-breg/src/postgres/context.rs. Review existing admission and mutation tests, verify that each mutation admits submitter targets once, and confirm the prior target context is preserved or invalid entry is rejected without changing authorization results.

Written by the indexing model from the issue text.