fix(deploy): reject colliding fleet name before provisioning an instance

[brettchien]

Summary

Brett hit this live: "New fleet" deploy on the k8s path deployed the instance (Hera) fine, then fleets-k8s.toml update failed: TOML parse error ... duplicate key \studio-agents` in table `fleet`— because a k8s fleet namedstudio-agents` already existed.

Root cause: appendFleetBlock/appendK8sFleetBlock (console/src/fleetToml.ts / fleetsK8sToml.ts) always append a brand-new [fleet.<name>] block — there's no merge path, since fleet_config_write/k8s_fleet_config_write are whole-file verbatim writes (studio#104's documented no-partial/append-primitive tradeoff). Reusing an existing fleet name in "New fleet" therefore only surfaces as a duplicate-key parse failure after deploy_provision_agent already stood up the instance — the instance is live but never gets registered as a fleet member (the write is rejected before touching disk, so the config file itself isn't corrupted, just stale).

Compounding factor: adding an instance to an existing k8s fleet isn't wired through the wizard yet (see the isK8s comment in deploy.ts's deploy-submit handler), so reusing "New fleet" for that case is currently the only UI path — making this collision easy to hit.

Fix

Check the fleet name against the target config (fleets.toml or fleets-k8s.toml, per the provider picker) in the identity-form submit handler, and block with an actionable message before Step 2 can deploy anything:

a fleet named "studio-agents" already exists — use "Add instance" on that fleet instead

New fleetBlockExists export in fleetToml.ts (reused by both configs, same as appendMember).

Not fixed here

• Add-instance-to-existing-k8s-fleet is still not wired through this wizard — that's the real workaround Brett needs, tracked separately (this PR just stops the wizard from silently eating a deploy when someone hits the gap).
• Brett's live Hera k8s instance from this incident is already deployed but not registered in his local fleets-k8s.toml — that's a local file on his machine, needs manual reconciliation (add Hera's service name to [fleet.studio-agents]'s members), not something this PR touches.

Test plan

• npm run typecheck — clean
• npx vitest run — 103/103 passing, incl. 3 new fleetBlockExists cases