Entity picker input indistinguishable from its options; opening does not focus or select #735

Summary

The searchable entity picker (#512, NamedEntityPicker) does not read as a search box once it is open. Its input is styled identically to the listbox rows beneath it, and opening it neither focuses the input nor selects its text, so a user sees a highlighted "first row" with no cue that they can type to search. On a farm with more than 50 flocks this is the only way to reach a flock past the first page (observed: a newly created Test Flock sorted at row 102 of 102, first window shows rows 1–50).

Where it shows

Every consumer of NamedEntityPicker — same component, same CSS, same behaviour. Counted from grep -rn "<FlockPicker\|<CustomerPicker" web/src/routes:

11 instances across 7 screens. No other input-above-list control exists in web/src: Settings' timezone field is a native <datalist> (browser-rendered, out of scope); Help's search is a plain type="search" input with a magnifier icon and a "Search…" placeholder — the precedent this picker should match.

Two defects

1. No visual distinction between the input and the options.
.named-picker-control input (styles.css ~L2876) and .named-picker-listbox (~L2900) share background: var(--surface), border: 1px solid var(--hairline), border-radius: var(--r-input), and near-identical padding/font size; .named-picker-option rows sit 0.25rem below. Dark theme: both #221a26. On open the input's value is the committed entity's name (displayText = d.rawQuery, seeded from the committed value), so it renders as one more row of the same text. No icon, no search placeholder (the placeholder is the committed name by spec FR-018).

2. Opening does not focus the input or select its text.
The closed state is a .named-picker-trigger button; clicking it swaps in the combobox. The engine's only inputEl?.focus() calls are the two Retry paths (~L457, ~L494). Nothing runs on open, so the input appears unfocused with the previous name in it. Expected: on open, focus the input and select all of its text — the standard combobox cue that typing replaces the current value — so the first keystroke starts a search rather than appending to "Sim House A".

Proposed fix

CSS + one behaviour change in the shared component; no page edits.

• Input: inset look (background: var(--surface-2)), a leading magnifier icon (inline SVG background-image, padding-left ~2rem, match .help-search-field svg), accent border while aria-expanded="true".
• Listbox: keep --surface so it reads as a floating sheet above an inset field; widen the gap slightly.
• On open becoming true: inputEl.focus(); inputEl.select(); (both dark/light themes must be checked; the .named-picker-option.active tint stays).

Not in scope: changing type="text" to type="search" (the browser clear (×) would sit beside the picker's own Clear control), the placeholder text (spec FR-018), the combobox ARIA markup.

Acceptance

• Open picker: input visibly distinct from options in both themes; magnifier visible; input focused with all text selected; typing one character replaces the text and filters.
• Keyboard flow from spec SC-004 unchanged (Tab into trigger, Enter/Space opens, arrows/Enter/Escape as today).
• Vitest: assertion that open ⇒ document.activeElement is the input and selectionStart === 0 && selectionEnd === value.length; a class/attribute assertion for the expanded styling hook.
• 1:1 before/after screenshots from a rebuilt stack in the PR (AGENTS.md AGENTS.md: three conventions earned while shipping #651 + #652 #662 rule), dark and light.
• Existing NamedEntityPicker tests green; web/ coverage floor not lowered.

Refs: #512 (picker), #646 (default flock resolution), specs/001-searchable-entity-picker/spec.md.