Fix Browser Use trusted hash patch drift

[joshyorko]

Summary

• add the current vo Browser Use runtime factory name to the node_repl approval/trusted-hash patch allowlist
• add a regression fixture for the t.vo({ ... trustedBrowserClientSha256s: d ... }) runtime config shape

Why

The 26.623 bundle can emit Browser Use node_repl runtime config through t.vo(...). The Linux patch already handles earlier minified factory names, but this drift means it can miss both the JS auto-approval insertion and the Linux trusted browser-client hash wrapper. When that happens, rebuilt Linux bundles can keep stale trusted client hashes and reject the bundled Browser/Chrome client transport.

Validation

• node - <<'NODE' ... NODE focused assertion against applyBrowserUseNodeReplApprovalPatch for the vo fixture: passed
• node --test scripts/patch-linux-window-ui.test.js: Browser Use node_repl fixtures passed, including the new vo fixture; the full file still exits non-zero on this Bluefin host because the unrelated existing package-profile test package profile distinguishes Fedora package managers by major version sees rpm-ostree where it expects dnf

Scope

This branch is based on upstream/main and contains only the two Browser Use patch/test changes.

[ilysenko]

Thanks for the update. I found a blocker:

• This touches upstream-drift patch logic, but it extends the runtime factory allowlist (Dn|Pn|Fa|La|Ha|vo|$a) instead of removing the legacy factory names.
• Per CONTRIBUTING.md, drift fixes need to target the current CODEX.DMG only; please keep the current vo shape and drop the older DMG compatibility names in the same PR.