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.

crates/registry-breg/src/mutation/request.rs の汎用的な Submit/Revise パス、submit ルーチン、および admit_submitter_targets から始め、その後 crates/registry-breg/src/postgres/context.rs のコンテキスト処理を読んでください。既存の admission テストと mutation テストを確認し、各 mutation が submitter のターゲットを 1 回だけ admit することを検証し、以前のターゲットコンテキストが保持されるか、認可結果を変更せずに無効なエントリが拒否されることを確認してください。

索引モデルが issue の本文から書いたものです。