#32436 cmux-cloud-start-core: the start's checks, the vm-kind word, the machine login reading, and one harness login call (step A)

Leo: "BUT WHY THE FING ARE THERE SO MANY TESTS IN FING SWIFT / IT'S CLOUD CODE / WHY IS IT NOT IN RUST". New logic goes in Rust; Swift stays a thin shell.

Step A of the next Cloud start move (the repo's two-step app FFI pattern, as #32305 then #32403): the Rust and its C ABI, no Swift change. Step B re-pins the app FFI and deletes the Swift copies and their tests.

What moves into cmux-cloud-start-core (1:1 ports, no behavior change):

1. One harness login call (fixes #32416). cloud_harness_login now takes the raw facts: dogfood + setting (the passesHarnessLogin precedence), harness (the provider), guestStdout (the vm-kind probe output) and machineProbe (the machine login probe's exit code and stdout). It resolves them and returns the resolved gate, provider, guestKind, machineLogin and the guestKindProbe to run. So in step B the app makes one FFI call, and the only way that call can fail is ffi-failed. Today a helper op that does not answer reads as no-transfer-for-harness or guest-kind-unread. The older inputs (gate, provider, guestKind, machineLogin) still work. The helper ops (cloud_harness_login_provider, cloud_guest_kind, cloud_guest_kind_probe) stay for the app pinned now, until step B stops calling them.
2. start: CloudStartChat.refusal, accountText, checkAccount, the too-broad folder check (CloudMoveFolder.isTooBroad) and the upload-root guard (AgentPaneCloudStart.uploads). The disk reads (standardizing, realpath, the working copy's git folders) stay in the app; the rule gets their results. Ops: cloud_start_refusal, cloud_start_account_text, cloud_start_check_account, cloud_folder_too_broad, cloud_start_uploads.
3. vm_kind: the attach answer's vmKind word (callerOwnsVM, callerIsTeammate, CloudMachineLink.vmKindArguments). Op: cloud_vm_kind.
4. machine_login: CloudMachineLogin.parse and fingerprint (SHA-256 hex; sha2 is already in the app FFI's lock). Op: cloud_login_fingerprint. The parse is reached through machineProbe above.

Not touched: CloudMachineCreateFlow and CloudConfiguration.

Tests

cmux-ci test (fast checks run 41475377188, source 80dd302be67):

• cargo test -p cmux-cloud-start-core: 28 passed (16 new; the ports of the Swift cases that step B deletes).
• cargo test --test cloud_harness_login in cmux-layout-reducer-ffi: 7 passed (3 new, through the C ABI).
• cargo clippy --all-targets -D warnings on both crates: clean.

Observed / Not run

Observed: the cargo runs above. Not run: any Swift build. This PR changes no Swift, and the app still links the pinned FFI release until step B.

Changelog

none

Agent session: agent session

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Step A of moving the Cloud start's checks from Swift into Rust: the start's refusal, account and folder checks, the vm-kind word, and the machine login probe's reading now live in cmux-cloud-start-core, exposed through new FFI ops (cloud_start_*, cloud_vm_kind, cloud_login_fingerprint). cloud_harness_login now reads the raw facts—the build gate, the harness, and both probes' output—and resolves them in one call, so the only failure it can report is ffi-failed instead of today's no-transfer-for-harness or guest-kind-unread.

The older gate, provider, guest_kind, and machine_login inputs still work; cloud_harness_login_provider, cloud_guest_kind, and cloud_guest_kind_probe remain for apps pinned before this change. Step B re-pins the app FFI and drops them. No Swift changes—the app still links the pinned FFI release. Adds the sha2 dependency for the login fingerprint SHA-256.

Tests: 28 cargo test cases pass in cmux-cloud-start-core (16 new ports of the Swift cases step B deletes), 7 FFI cases through the C ABI, and clippy is clean.