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.

Comienza en crates/registry-breg/src/mutation/request.rs, en la ruta genérica de Submit/Revise, la rutina de submit y admit_submitter_targets; después, lee el manejo del contexto en crates/registry-breg/src/postgres/context.rs. Revisa las pruebas existentes de admission y mutation, verifica que cada mutation admita los destinos del submitter una sola vez y confirma que el contexto del destino anterior se conserve o que se rechace una entrada no válida sin cambiar los resultados de autorización.

Escrito por el modelo de indexación a partir del texto del issue.