hooks: surface legacy millisecond command-hook timeouts at startup

Summary

#11615 changes command hook timeout to seconds and keeps values of 1000 or more working as legacy milliseconds. Today the only notice that a hook still uses the old form is a debug-log line written the first time that hook runs. A startup warning was prototyped in #11615 and removed from it during review, because doing it safely needs more design than that PR should carry. This issue records the requirements so it can land as its own change.

Requirements

1. Never echo untrusted text raw. A repository-committed .qwen/settings.json is untrusted input. The warning must not print a hook's command. If it names the hook, run the label through stripAnsiAndControl, drop Unicode format characters (\p{Cf}: bidi overrides, zero-width characters, BOM), trim it, and cap it at the existing 64-character echo limit used for output-style names. Identifying the hook by position (hooks.<Event>[i]) plus the settings file path is an acceptable alternative. Startup warnings are written with a raw process.stderr.write before the UI renders, so escape sequences would reach the terminal and the clipboard.
2. Cover every scope whose hooks run. System and SystemDefaults settings are merged as overrides and their hooks execute regardless of folder trust, so managed hooks need the warning too. Walk those scopes in a separate loop so admin-managed files do not also start producing legacy settings-key warnings.
3. Only warn when there is something to do. A value of 1000000 or more cannot be rewritten in seconds while the legacy reading is supported, and the guide tells users to keep such values in milliseconds. Do not warn about them on every launch.
4. Do not claim a reading for hooks that will not load. Workspace hooks in an untrusted folder, under --safe-mode, or with disableAllHooks are never loaded. Either skip them per scope (not with one trust check over all scopes, which would hide managed hooks) or word the message as "would be read as … when this hook runs". Safe mode is resolved from argv or the environment, so the early startup call site cannot read it from Config.
5. Tests that can fail. Cover a workspace-scope file (the existing fixture only makes the user settings file exist), an HTTP hook that has a name so the command-only filter is actually exercised, a managed-scope file, the 1000000 band, and a label with escape and format characters. Prove each by mutation.
6. Update the timeout paragraph in docs/users/features/hooks.md to describe the warning once it exists.

Related

• #11610 (hooks alignment tracking issue)
• #11615 (timeout unit change, where the prototype and review discussion live)

Start by reading #11615 and tracing the early startup hook-loading path, including stripAnsiAndControl and the safe-mode sources. Add mutation tests for workspace, managed, HTTP, large-timeout, and escaped-label cases, then update docs/users/features/hooks.md. Done means startup warnings are safe, scoped correctly, actionable only when conversion is possible, and all listed tests pass.