feat(deploy): wire k8s provider through New Fleet wizard submit (studio#104)

[brettchien]

Summary

Connects the New Fleet wizard's actual submit path to the k8s dispatch that's been backend-reachable since #117 (Tauri bridge fix). deploy.ts's identity step previously hard-blocked provider === "k8s" with "Kubernetes provisioning isn't available yet — tracked in #104" — that block is removed, and deployForm's submit handler now branches on provider:

• k8s: calls deploy_provision with provider: "k8s", context (selected kubeconfig context), and expected_principal built from the selected namespace + service account in the system:serviceaccount:<ns>:<name> form provision_from_library_k8s expects (it extracts the bare name itself). On success, appends the new fleet to fleets-k8s.toml.
• aws: unchanged.

New: k8s_fleet_config (read)

Appending a fleet block needs the current file text first (appendK8sFleetBlock, same pattern as AWS's appendFleetBlock) — but only k8s_fleet_config_write existed, no read counterpart. Added k8s_fleet_config (MCP tool in oab-mcp + #[tauri::command] bridge in src-tauri, mirroring fleet_config/fleet_config_write's existing pair) so the wizard can read-then-append instead of clobbering any existing fleets-k8s.toml content.

Also refactored t_k8s_fleet_write's fleet→JSON mapping into a shared k8s_fleets_json helper reused by both the new read tool and the existing write tool.

Scope note

Add-instance-to-an-existing-k8s-fleet isn't wired — the provider <select> only appears in the identity step, which "add instance" mode skips entirely (confirmed: reset() runs on every open() and puts the select back to its "aws" default), so this only covers new k8s fleets via the wizard. Fine for now; flagging so it doesn't look like an oversight.

Verification

• TS: npm run typecheck clean, npm test 106/106 passing, npm run build succeeds.
• Rust (crates/oab-mcp, src-tauri): not locally compiled — this environment reliably OOM-kills on aws-sdk-ec2 regardless of -j/codegen-units settings, a known pre-existing limitation (see fix(src-tauri): register missing Tauri command bridges for k8s onboarding tools (studio#104) #117's same disclaimer), not something new here. Every new/changed function is a small, mechanical mirror of an already-working sibling (t_fleet_config/fleet_config for the read tool+bridge; t_k8s_fleet_write's existing mapping logic for the shared helper), hand-verified line by line against them. CI's build-test + bundle-macos jobs are the real gate here.
• Not yet verified against the actual running app (this environment can't run the Tauri desktop shell) — recommend re-testing the New Fleet → Kubernetes → submit path for real before treating this as fully done, same as fix(src-tauri): register missing Tauri command bridges for k8s onboarding tools (studio#104) #117.

Ref #104.

🤖 Generated with Claude Code