fix(config): translate the approval card's security note in the zh UI

[yudongyouqing]

Summary

• change_view now sends sensitive_key (the path a reason belongs to) beside the English sensitive sentence, so the card can translate the note; the sentence itself stays untouched because raven_config describe shows it to the model.
• The approval card renders the note through gui.confirm.cfg.why.<path> and falls back to the English sentence when the catalogue has no entry.
• i18n/messages.json gains every reachable reason (19 catalog settings + 70 channel fields, counting the host's enabled / allow_from / workspace socket fields) in both locales; ui-tui/src/i18n/messages.generated.ts regenerated from it.
• New tests/test_i18n_sensitive_notes.py walks the catalog and the channel specs and holds the catalogue to them: an entry exists per reason, the en column equals the source sentence, and zh is present, so new reasons cannot regress silently.

Type

• Fix

Verification

• Relevant tests pass locally: uv run pytest tests/test_i18n_sensitive_notes.py tests/test_config_self_surface.py -> 105 passed; uv run pytest tests/test_raven_config_tool.py -> 131 passed; npx vitest run src/features/composer/approve.test.ts -> 50 passed
• Relevant lint / type checks pass locally: ruff check + ruff format --check on the changed files; ty check at the pre-change baseline (18 platform-only diagnostics on Windows); npm run type-check; eslint on the two changed web files; npm run gen:check -> generated.ts matches the contract (205 methods)
• User-facing docs or screenshots are updated when needed: not needed, catalogue strings only

Risk

• Security impact considered: only a translated rendering of an existing warning is added; the English sentence remains the fallback and the model-facing copy is untouched
• Backward compatibility considered: sensitive_key is additive, and a surface that ignores it keeps the previous behaviour
• Rollback path is clear: plain revert, no data or protocol migration

Related Issues

Fixes #851

[gloryfromca]

Blocking: accepted camelCase channel paths still leave the zh security note in English.

I reviewed the full diff and the relevant self-configuration, channel normalization, approval-card, and i18n code and history. I also checked AGENTS.md, CONTEXT-MAP.md, the Runtime/Web UI architecture constraints, compatibility with accepted path aliases, and that the added tests were not weakened.

Verification: uv run pytest tests/test_i18n_sensitive_notes.py tests/test_raven_config_tool.py -x (132 passed); npm test -- --run src/features/composer/approve.test.ts in ui-web (50 passed); node scripts/gen-i18n.mjs --check in ui-tui (up to date); uv run python scripts/check_source_language.py github/main...HEAD (passed); git diff --check github/main...HEAD (passed). The focused suites pass but do not exercise an accepted camelCase channel-field spelling.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

Reviewed the current revision and confirmed the earlier camelCase channel-path blocker is fixed for direct and object-nested sets. The declared-key normalization also correctly covers wildcard setting instances.

Coverage: AGENTS.md and CONTEXT-MAP.md; the Runtime and Web UI architecture constraints; the full diff and follow-up commits; self-configuration and approval-card callers; relevant history; backward compatibility with runtimes that omit sensitive_key; and whether the tests were weakened. No new findings. The thread I opened is resolved.

Verification: uv run pytest tests/test_i18n_sensitive_notes.py tests/test_raven_config_tool.py tests/test_config_self_surface.py tests/test_permissions_gate.py -x (550 passed); npm test -- --run src/features/composer/approve.test.ts in ui-web (50 passed); node scripts/gen-i18n.mjs --check in ui-tui (up to date); uv run python scripts/check_source_language.py github/main...HEAD (passed); git diff --check github/main...HEAD (passed).