Sync asset-scoped jurisdiction governance updates

docs/04-configuration/GRU_STORAGE_GOVERNANCE_AND_SUPERVISION_STANDARD.md

@@ -49,13 +49,16 @@ This creates one place to express supervisory expectations without hardcoding a
 
 - Governance proposals are created per asset through `GovernanceController.proposeForAsset`.
 - The jurisdiction review id, review-required flag, and minimum notice period are derived from `UniversalAssetRegistry` state for that asset instead of being manually tagged afterward.
+- Jurisdiction-policy changes in the registry are executed through asset-derived registry entry points so the affected jurisdiction is still anchored to a concrete registered asset.
 - When the derived asset profile is jurisdiction-review-sensitive, a proposal cannot be queued until at least one authorized jurisdictional authority has approved it.
+- If a proposal changes an asset’s primary jurisdiction, it must collect approval from both the current jurisdiction and the destination jurisdiction before queueing.
 - The queue delay must respect the larger of:
   - the proposal’s governance-mode timelock
   - the asset’s derived minimum upgrade notice period, including stronger jurisdiction defaults from the registry
 - Asset-scoped proposals can only target:
   - the asset contract itself
   - registry calls whose scoped asset argument matches the proposal asset
+  - asset-derived registry jurisdiction entry points that resolve policy updates from that same proposal asset
 
 This is now enforced in the shared governance controller, so “upgradeability” is not only a proxy question but also a policy and supervision workflow question.