feat(frontend): add pool selector to create actor dialog advanced options

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5496 feat(rivetkit): add per-call poolName option to getOrCreate …
• #5542 fix(frontend): source actor deployment logs pool from runner …
• #5540 feat(frontend): add pool selector to create actor dialog adv … 👈
• #5541 feat(frontend): delete managed pool from compute config page
• #5499 feat(frontend): pool switcher and pool-scoped titles for log …
• main

Get stack: forklift get 5540
Push local edits: forklift submit
Merge when ready: forklift merge 5540

_{change yoopttno}

[claude]

Review: feat(frontend): add pool selector to create actor dialog advanced options

Overview

Adds a Pool selector (backed by namespace runner-config keys) to the Advanced section of the create-actor dialog/sheet for the non-features.datacenter (OSS-style) branch, plus a useDefaultRunnerNameSelector() hook so the resolved default pool is submitted even when the user never opens Advanced.

This is an updated pass on the latest commit — the previous eager-pagination-drain concern from my earlier comment on this PR has been fixed: useRunnerConfigKeys no longer has a useEffect that drains every page on mount. It now wires hasNextPage/fetchNextPage straight into Combobox's onLoadMore, matching the existing all-runner-select.tsx -> useAllRunners() pattern (fetch-on-scroll, not eager-fetch-all). The duplicated select callback was also deduped into the shared selectRunnerConfigKeys const used by both the real and noop query options. Good fixes.

Remaining observations (minor, non-blocking)

• Duplicated "resolve default pool" computation: Pool() and useDefaultRunnerNameSelector() each independently call useRunnerConfigKeys() and separately run resolveDefaultPool(keys). They agree today because both read the same react-query cache key and the same pure function, but it's two independent call sites computing "the default" rather than one source of truth. Since the query cache is shared, this doesn't cause an extra request, but consider exposing a single hook/context so future edits to either call site can't silently diverge.
• Controlled value vs. RHF state: Pool's <Combobox value={field.value || defaultPool || ""} ...> displays defaultPool without ever calling field.onChange(defaultPool). This is fine given the submit handlers re-derive the same fallback (values.runnerNameSelector || defaultRunnerNameSelector), but the visually-selected value and the actual RHF field value diverge until the user explicitly touches the control. Worth a quick check that nothing else (dirty-state tracking, validation) reads runnerNameSelector directly before submit. This does follow the repo's guidance to avoid effect-based prefill for derived state, so it's a reasonable tradeoff, just flagging the divergence explicitly.
• runnerConfigsQueryOptions() called without a variant filter: unlike all-runner-select.tsx, which filters to { variant: "serverless" } for its runner-config half, useRunnerConfigKeys fetches all variants (serverless + normal). That looks intentional here (Pool is meant to represent "any pool you can target"), but worth double-checking that a normal-variant runner config is actually a valid runnerNameSelector target in the non-datacenter/OSS path. If only serverless pools are selectable there, this would surface pools that error on submit.
• resolveDefaultPool only looks at the first fetched page(s): if a namespace has enough runner configs to paginate and "default" isn't in the pages fetched so far, resolveDefaultPool picks keys[0] (whatever happened to load first) instead of "default" until more pages are pulled in. Edge case for large pool counts, but worth a mental note since it affects the actual submitted value, not just display.
• Naming collision with existing "pool" concept: useHasManagedPool() / "managed pool" already means something distinct (cloud-only Rivet Compute pools) elsewhere in actor-details-shared.tsx. A new user-facing "Pool" label for runner-config keys in the OSS/self-host path is a different concept with the same name. Might be worth a more specific label (e.g. "Runner pool") if there's any chance these two "pool" surfaces are ever visible in the same context, though today they're mutually exclusive by feature flag so it's unlikely to confuse in practice.

Test coverage

No tests or Ladle story added. Per frontend/CLAUDE.md's story guidance, a story is reasonably skippable here since Pool depends on the data-provider/react-query stack. resolveDefaultPool is a small pure function that would be cheap to unit test if you want coverage without the full provider stack, but it's low-risk logic.

Nit

• Exporting a component named Pool from actor-create-form.tsx is generic in isolation, but reads fine at call sites via the ActorCreateForm.Pool namespace import.

Overall this looks solid and the main structural issue from the previous round (eager pagination drain) is resolved. Remaining points above are minor polish, not blockers.