fix(registryctl): permit tutorial purpose in generated notary policy

[jeremi]

Problem

The "Evaluate a claim with Registry Notary" tutorial fails at its central step on both released v0.8.3 and current main. registryctl notary smoke fails at "notary evaluator can verify starter claim" (expected 200, actual 403), and the tutorial's own evaluate curl returns 403 pdp.purpose_not_permitted (matching_policy_id notary.source_binding.relay.benefits_casework.person) for the tutorial's own purpose URI. The 409 evidence.not_available teaching point is unreachable for the same reason. Found by a full black-box reader run of the published tutorial.

Root cause

The benefits template (crates/registryctl/src/templates/notary_config.yaml.tmpl) declared the person source binding with no matching.allowed_purposes. Source-binding PDP policies are built fail-closed (permit_unconstrained: false in registry-notary-server/src/runtime.rs; empty purpose_constraints denies in registry-platform-pdp), so the generated sample denied every purpose, including its own documented one. The OpenCRVS/DCI template already allow-lists the same tutorial purpose, confirming the server behavior is intended and the fix belongs in the generated config.

Changes

• fix(registryctl): permit tutorial purpose in generated notary policy: add a matching.allowed_purposes block containing only https://example.local/purpose/tutorial to the benefits notary template. Test-first: local_relay_notary_config_permits_tutorial_purpose parses and validates the generated config and asserts the allow-list.
• fix(registryctl): always print docs URL for open commands: registryctl open / notary open printed nothing in headless sessions because macOS open exits 0 even with no display, so the documented fallback never fired. The commands now always print the URL(s), then best-effort launch a browser. Output extracted into unit-testable helpers with tests.

Security review notes (authorization/policy defaults)

• The change permits exactly one additional purpose in the local sample project that registryctl generates. It does not alter production defaults, shared PDP behavior, or any committed runtime config.
• Purpose is the only gate added; no legal-basis, consent, jurisdiction, or assurance constraints are relaxed.
• The server keeps failing closed on empty allow-lists (unchanged behavior, re-verified).

Verification

• cargo fmt --check, cargo check --locked --workspace --all-targets, cargo clippy -p registryctl --all-targets -- -D warnings, cargo test --locked -p registryctl: all green.
• End to end against the pinned notary image: all 7 registryctl notary smoke checks pass; the tutorial's evaluate curl for per-2001 returns 200 with satisfied: true; per-9999 now returns the documented 409 evidence.not_available.

Known related issues, deliberately not in this PR

• Current-main registryctl no longer emits the commitment fingerprint field the pinned released relay image requires, so a project generated by a locally built registryctl fails to start the pinned relay (missing field commitment). Separate relay-config drift.
• Live problem-type URIs use dead domains (registry-relay.dev, docs.registry-notary.dev); domain consolidation is tracked separately.
• The v0.8.3 registryctl asset self-reports 0.1.0; already fixed on main via version.workspace = true.

[jeremi]

Two follow-up commits after a template audit:

• The standalone notary template (init notary, used for registry-data-api and FHIR sidecar sources) had the same defect: no matching.allowed_purposes, so the shared notary smoke evaluate check (which always sends the tutorial purpose) was denied fail-closed. Fixed test-first (standalone_notary_config_permits_tutorial_purpose). The OpenCRVS/DCI template was already correct.
• Reworded the generated-config comments for the adopter reading the file rather than the reviewer of this change: the allow-list comment now states the field's contract (deny-by-default, the pdp.purpose_not_permitted error code, what to edit), the three notary templates gained orientation headers matching the relay template's voice, and the DCI template warns that matching context constraints must stay in sync with the evaluator key's authorization_details.

Same security posture as before: one purpose permitted in generated local sample configs only.