fix: sync manager user script runtime status

[Rat0323]

What changed

• add a read-only one-shot CDP probe for window.__codexPlusUserScripts.scripts
• merge live renderer status into the standalone Manager's local script inventory
• refresh live status when opening Script Market and after enabling, disabling, or deleting a script
• gracefully fall back to filesystem inventory when Codex is not running or CDP is unavailable
• normalize all byte-exact upstream theme assets to LF to prevent recurring Windows checkout hash failures

Why

PR #1611 fixed runtime status reporting in the Codex-embedded user-script panel, but the standalone Codex++ Manager still called UserScriptManager::inventory() without renderer state. As a result, scripts that were actively running appeared as not_loaded in Script Market > Local scripts.

The new probe opens a short-lived, read-only CDP connection and reads the existing renderer registry directly. It does not reinject scripts and does not call the renderer bridge from inside CDP.

Validation

• npm test (36 passed)
• npm run check
• npm run vite:build
• cargo check -p codex-plus-manager
• cargo test -p codex-plus-core runtime_status_tests (2 passed)
• cargo test -p codex-plus-core --test upstream_theme_assets (2 passed after LF normalization)
• cargo test --workspace: all suites passed through the launcher tests; the pre-normalization run then reproduced the known Windows byte-exact EOL failures, which are covered by the included .gitattributes fix and the focused rerun above

Follow-up to #1611.

[BigPizzaV3]

维护者审查：该 PR 的状态探测依赖 target 选择修复，不能按当前分支独立合并。

live_runtime_status 使用 pick_injectable_codex_page_target，而此 PR 基线中的实现只按 title/url 含 codex 选择 primary page，没有排除 Codex++ Manager。该功能又恰好从 standalone Manager 发起；当同一调试端口枚举出 Manager 与 Codex 主页面时，可能连接到 Manager 自己，读取到空 registry，然后把正在运行的脚本显示为 not_loaded。

#1730 已新增 Manager 排除和 Codex 主页面优先选择，说明这个场景确实存在。建议先处理 #1730 中的 target picker（可拆成独立小 PR），再将本 PR rebase 到该实现；同时补一个 targets 同时包含 Manager 和 Codex 主页面的测试，断言 probe 选择 Codex 主页面。

另外 #1730 当前还有脚本 cleanup 生命周期问题，因此更稳妥的顺序是先拆出/合并纯 target picker 修复，再合并本 PR，而不是让本 PR 依赖整套热重载功能。