Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success

Start at crates/socket-patch-core/src/patch/redirect/mod.rs:1062 and compare workspace handling with crates/socket-patch-core/src/vendor/cargo.rs:1506. Reproduce the issue from cargo_hosted_workspace_member_declaration_is_pinned in crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs using a member as --cwd. Done means hosted mode resolves the workspace root or refuses with no files written, with regression coverage for this case.

[agent] Found by the scheduled Cargo bug-hunt routine (ledger #315).

Summary

Take a cargo workspace whose Cargo.lock lives at the root, and run socket-patch scan --mode hosted (or a bare scan) with --cwd pointing at a member directory. Hosted mode treats the member as a standalone lockless project, because there is no Cargo.lock beside it and its only dependency is the patched crate. So it:

• adds registry = "socket-patch-<uuid>" to the member's Cargo.toml,
• writes the [registries.socket-patch-<uuid>] block to the member's .cargo/config.toml,
• leaves the workspace root's Cargo.lock untouched (rewrittenFiles is [".cargo/config.toml", "Cargo.toml"], both relative to the member),
• exits 0 with redirected: 1 and no warnings.

The workspace is then broken whichever directory you build from:

• From the workspace root, cargo doesn't read the member's .cargo/config.toml, so the manifest no longer parses: failed to parse manifest at …/direct/Cargo.toml … registry index was not found in any configuration: socket-patch-c1f90104-….
• From the member, the root lock still pins crates.io, so cargo fetch --locked fails with cannot update the lock file …/Cargo.lock because --locked was passed.

Any other member that inherits the crate through [workspace.dependencies] stays unpatched as well.

Impact

A "successful" scan leaves a workspace that can't build at all from the root, and can't build --locked anywhere. A fresh checkout in CI fails, and so does any cargo build a developer runs from the workspace root. Running socket-patch from inside a crate directory of a monorepo is an easy mistake to make, and it produces no warning.

Repro

This uses the shape cargo_hosted_workspace_member_declaration_is_pinned from crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs, with the scan's --cwd set to <proj>/direct instead of <proj>. That's a one-line local change; everything else, including the wiremock patch API and the sparse registry, is unchanged.

proj/Cargo.toml          [workspace] members = ["inherits", "direct"]
                         [workspace.dependencies] cfg-if = "1.0.4"
proj/inherits/Cargo.toml cfg-if = { workspace = true }
proj/direct/Cargo.toml   cfg-if = "1.0.4"
proj/Cargo.lock          (generated at the root, cfg-if 1.0.4 from crates.io)

$ socket-patch scan --mode hosted --json --yes --cwd proj/direct --api-url <mock> --org test-org --api-token fake
  -> exit 0, redirect.redirected = 1, warnings = [], rewrittenFiles = [".cargo/config.toml", "Cargo.toml"]
$ git -C proj status --porcelain
  M direct/Cargo.toml          # cfg-if = { version = "1.0.4", registry = "socket-patch-c1f9…" }
  ?? direct/.cargo/config.toml # [registries.socket-patch-c1f9…] index = "sparse+…"
  (Cargo.lock unchanged)
$ (cd proj && cargo fetch --locked)
  error: failed to load manifest for workspace member `…/proj/direct`
  Caused by: registry index was not found in any configuration: `socket-patch-c1f90104-5a0c-4e7a-9c0d-1a2b3c4d5e01`
$ (cd proj/direct && cargo fetch --locked)
  error: cannot update the lock file …/proj/Cargo.lock because --locked was passed to prevent this

It reproduced on every run (4 of 4).

Expected vs actual

• Expected: CLI_CONTRACT.md: "A workspace member that shares its root's lockfile is part of that root's project." Hosted mode should either resolve the workspace root (the directory holding the Cargo.lock that the member's [workspace] points to) and rewrite there, or refuse loudly with nothing written. Vendored mode already refuses this case with cargo_manifest_not_workspace_root ("run from the workspace root"). ecosystems.md's lockless rule ("with no Cargo.lock the graph is unknown, so only a project whose sole dependency is the patched crate is redirected") assumes the directory really has no lock. A member whose workspace root has one isn't lockless.
• Actual: success, redirected: 1, and a workspace that no longer builds.

Matrix

I didn't bisect it. It's present on main 2463257 (after #277).

Suspect code

• crates/socket-patch-core/src/patch/redirect/mod.rs:1062 (rewrite_cargo): it plans against the candidate files of --cwd only, so with no Cargo.lock in files it takes the lockless path, even though the member's manifest is part of a workspace. That shows as a parent Cargo.toml with [workspace] listing it, or a package.workspace key.
• There's no hosted counterpart to crates/socket-patch-core/src/vendor/cargo.rs:1506 (NOT_WORKSPACE_ROOT), the vendored-mode guard for this exact situation.

Related, but a different mode: #338 (agent mode run from a workspace member patches the wrong copy).