Fix hosted MCP token minting in no-auth mode

[abrookins]

Problem

In self-managed no-auth mode, a control-plane MCP token could already do useful control-plane work such as listing or creating workspaces, but it failed at the next required step: mcp_token_issue returned authentication required.

That left the hosted MCP flow internally inconsistent:

• the token could manage workspaces
• the same token could not mint the workspace-scoped MCP token needed for file access
• fs.mount() stayed broken for SDK clients that depend on that handoff

In practice, this blocked the mounted-filesystem path for the SDKs even though the rest of the hosted control-plane token flow looked healthy.

Fix

• allow ownerless self-managed control-plane MCP tokens to mint workspace-scoped MCP tokens when the token is control-plane scoped
• keep the stricter auth behavior for other paths unchanged
• add an end-to-end hosted MCP regression test that proves control-plane token -> mcp_token_issue -> workspace token works
• add Python SDK mounted-FS happy-path coverage for FSClient.mount() so the SDK path that originally exposed the problem stays covered

Why the extra test changes are here

This branch also updates two stale cmd/afs tests that were already failing the local repo gate for unrelated reasons:

• one test was reading real machine mount state instead of isolated test state
• one test still used the removed -w filesystem flag

Those changes do not alter product behavior. They make the existing test gate reflect the actual branch state so the PR can run cleanly.

Testing

• go test ./cmd/afs -run 'TestCmdStatusShowsSignedInCloudState|TestCmdFSHistoryReportsExistingFileWithoutRecordedHistory'
• go test ./internal/controlplane
• PYTHONPATH=src uv run python -m unittest tests.test_client
• make test
• uv run --with build --with twine python -m build
• uv run --with twine python -m twine check dist/*

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}