feat(help): enforce owner-aware high-risk contexts

docs/CONTEXTUAL_HELP_CONTRACT.md

@@ -58,6 +58,17 @@ than adding custom `F1` listeners:
   headed pages. `WorkspaceLayout` owns the full-canvas workspace scope and its
   labelled primary/content panes; pages inside it use `PageLayout` in
   `workspace` mode and retain their own route-level help identity.
+- `PasswordField` passes its owner context and module through reveal/generate
+  actions and the shared generator dialog. Credential consumers must supply an
+  exact owner context; the generic component does not own credential policy.
+
+High-risk controls use one of the source-inventory risk classes (`authority`,
+`credential`, `disclosure`, `encryption`, `external-effect`, `irreversible`,
+`policy`, or `retention`) and require exact F1 help. The extractor infers
+obvious cases conservatively; components may declare `data-help-risk`
+explicitly or mark a reviewed ordinary control with
+`data-help-risk-reviewed="standard"`. The strict workspace gate rejects new
+unresolved high-risk debt.
 
 Module routes, public routes, settings sections, and administration sections
 may also declare `helpContextId` and `helpTopicId`. Each module must keep a

docs/LOCALIZATION_AND_HELP_QUALITY.md

@@ -75,6 +75,17 @@ native control nested in `FormField`. Dynamic context expressions remain
 separate evidence and generic derived fallbacks remain in the richer-help
 candidate queue.
 
+The same inventory classifies controls whose labels, identities, component
+context, or explicit `data-help-risk` indicate authority, credentials,
+disclosure, encryption, external effects, irreversible changes, policy, or
+retention. These controls require an exact context rather than relying only on
+page fallback. Reviewed false positives carry
+`data-help-risk-reviewed="standard"`. Invalid risk classes and any increase
+above the versioned `tools/inventory/high-risk-help-baseline.json` ceiling fail
+strict declaration checks; the ceiling is lowered as the finite queue is
+resolved. Password fields and their generator dialog propagate the owning
+field's context so shared credential controls never invent a Core-owned topic.
+
 The generated `help_review_candidates` list is therefore a content-depth queue,
 not a list of controls on which F1 cannot work. It should prioritize:
 
@@ -109,6 +120,8 @@ The check must report:
 - no duplicate stable IDs;
 - no undeclared public WebUI surface;
 - no stale runtime route or endpoint declaration.
+- no invalid high-risk help annotation or regression above the recorded
+  exact-context debt ceiling.
 
 Browser acceptance is part of the focused workspace gate and can be run alone: