refactor(byoa): one source of truth for the engines a user can pick

[WhichPaths]

#101 had to follow #99 with four one-line additions, and they are all the same mistake:

-const PAIRABLE_ENGINES: ReadonlySet<string> = new Set(['claude', …, 'pi'])
+const PAIRABLE_ENGINES: ReadonlySet<string> = new Set(['claude', …, 'pi', 'gemini'])

-const [engine, setEngine] = useState<'claude' | … | 'pi'>('claude')
+const [engine, setEngine] = useState<'claude' | … | 'pi' | 'gemini'>('claude')

-{([['claude', 'Claude Code'], …, ['pi', 'pi']] as const).map(([id, label]) => (
+{([['claude', 'Claude Code'], …, ['pi', 'pi'], ['gemini', 'Gemini']] as const).map(([id, label]) => (

(the last two twice — once in MeView, once in Onboarding)

Gemini had an adapter, was detected, was labelled, and still could not be paired or selected, because four lists that are invisible from the adapter had not been told about it. Nothing errored.

The sharpest version of it: MeView already imports RUNNABLE_ENGINE_IDS and engineLabel — and then inlines its own copy of both, ten lines away.

Removing the copies rather than guarding them

src/lib/engines.ts declares the runnable engines once and derives the three shapes callers actually need:

export const RUNNABLE_ENGINES = ['claude', 'codex', 'grok', 'cursor', 'opencode', 'pi', 'gemini'] as const
export type RunnableEngineId = typeof RUNNABLE_ENGINES[number]
export const RUNNABLE_ENGINE_IDS: ReadonlySet<string> = new Set<string>(RUNNABLE_ENGINES)

Both pickers become:

{RUNNABLE_ENGINES.map((id) => (
  <button key={id} onClick={() => setEngine(id)} …>{engineLabel(id)}</button>
))}

and both useState unions become useState<RunnableEngineId>('claude'). There is no longer a list to forget.

The one that can't be derived, handed to the compiler

PAIRABLE_ENGINES is a server-side policy set ("engines a paired, non-cloud computer may advertise"), so it isn't simply the UI list. It becomes a Record over the engine union instead of a Set literal:

const PAIRABLE: Record<Exclude<EngineId, 'managed'>, true> = {
  claude: true, codex: true, grok: true, cursor: true, opencode: true, pi: true, gemini: true,
}
const PAIRABLE_ENGINES: ReadonlySet<string> = new Set<string>(Object.keys(PAIRABLE))

Adding an id to EngineId now fails to compile until it is classified. Verified by adding 'qwen' to the union:

server/src/agents/computer/registry.ts(54,7): error TS2741: Property 'qwen' is missing in type
'{ claude: true; codex: true; grok: true; cursor: true; opencode: true; pi: true; gemini: true; }'
but required in type 'Record<"claude" | … | "qwen", true>'.

That is better than a CI check for this one: it fails in the editor, before the commit exists. A new Set([...]) accepted the incomplete list in silence, and the engine left out could be detected and displayed but never paired.

One visible change

The picker rendered pi as "pi" while every other surface — including the engine list eight lines below it in the same file — renders engineLabel('pi') = "Pi". They now agree.

Checks

tsc (app + server), biome lint ., npm run build, both guards, and 39/39 across the engine test files. No behaviour change beyond the label, and the engine sets are byte-identical to what #101 left.

Complements #114, which guards the lists that can't be collapsed. This one deletes the ones that can.

[WhichPaths]

Note on ordering with the other open PRs, since three of these touch the engine lists:

• feat(byoa): run agents on Qwen Code #113 (Qwen) conflicts with this one on src/lib/engines.ts — both edit the RUNNABLE_ENGINE_IDS line. Whichever lands second resolves by adding 'qwen' to RUNNABLE_ENGINES and to the PAIRABLE record; the compiler points at the second one if it is missed, which is the point of the change.
• feat(ci): an engine is wired into all of its lists, or none #114 (registry guard) is complementary rather than overlapping: it guards the lists that cannot be collapsed into one declaration, and this PR deletes the ones that can. feat(ci): an engine is wired into all of its lists, or none #114's check reads RUNNABLE_ENGINE_IDS, which still exists here with the same contents, so it passes either way — I ran it against this branch.

Happy to rebase whichever order suits you.

[WhichPaths]

Correction to my note above: I said I had run #114's guard against this branch. I had not, and when I did, it failed — it anchored on RUNNABLE_ENGINE_IDS = new Set([...]), which this PR replaces with a derived form.

That is the guard behaving as designed (it reports anchor not found rather than passing vacuously), but it would have made the guard the thing blocking a change that removes the duplication it exists to police. I have pushed a commit to #114 so it reads either shape, and verified it against all three branches — this one, main, and #113.

Sorry for the unchecked claim.