fix: stop selecting controls disabled during focus

[ch-z-hc]

Bug

handleSelect focuses the control before changing its options. If a page's focus handler disables the select or its enclosing fieldset, the tool still changes the value, dispatches input/change and reports success.

For example, selecting ca on <select onfocus="this.disabled=true"> changes an initially us value even though the focus handler has disabled the control. This is reproduced against real headless Chrome through the production handler, not just a mocked DOM.

Fix

Check :disabled inside the existing page-side mutation function immediately before changing options. Return invalid_params without changing the value or dispatching events. Native selector semantics cover disabled fieldsets and the first-legend exception. No new RPC error reason or dependency.

Initially disabled controls retain Chrome's existing DOM.focus failure behavior. Enabled controls still select and dispatch events normally.

Validation

• Added unit and opt-in native Chrome regressions. Combined tests: 136 passed. The unchanged main with the same tests has 133 passed / 3 failed: the unit focus case and both native focus-handler cases.
• Final default extension suite: 2660 passed / 249 skipped. The new native suite is opt-in; all 7 cases were run explicitly with BSK_SELECT_CHROME in an isolated headless browser/profile.
• Extension TypeScript compile and production WXT build pass. Biome formatting/lint/import checks pass for all 3 changed files; repository-wide Biome with --formatter-enabled=false passes (646 files). Stylelint and DSH typecheck pass.
• DSH suite: 536 passed / 2 failed in the runner kill-grace tests. Unchanged main's runner suite has 31 passed / the same 2 failed. Those failures were not diagnosed or changed here. Rust and other opt-in browser suites were not run.

No existing assertions, timeouts or skip conditions were relaxed. Implemented and tested with Codex assistance; this is not a claim of human review or a fully green repository-wide suite.