fix(remote): fail closed on remote TTL expiry (no silent local fallback)

[cursor]

Summary

Fixes a security/correctness bug where expired remote workspace leases silently fell back to daemon-local execution.

Bug and impact

Impact: After a remote workspace TTL expires, bash / file / load_skill tools would silently execute on the cloud daemon instead of the user's remote machine. Commands intended for the laptop could mutate daemon-local paths — wrong execution environment without any user notice.

Root cause: get_remote_workspace_state() drops expired in-memory state and returns None. Tools interpreted that as "not in remote mode" and routed to local backends.

Trigger: User runs /remote-use ... --ttl 30m, continues the session past TTL, then asks the agent to run bash or edit files. Tools execute locally on the daemon while the user still believes they are on the remote workspace.

Fix

• Track sessions whose remote lease just expired (_REMOTE_TTL_LAPSED).
• bash, file, and load_skill tools return REMOTE_TTL_EXPIRED instead of falling back to local.
• Re-activating or releasing remote clears the lapsed flag.

Validation

• test_remote_ttl_lapsed_blocks_silent_local_fallback
• All tests in tests/test_remote_workspace.py pass

Notes

• Existing open PRs (fix(dashboard): restrict tasks/queue leak and gate config to admin #13, fix(dashboard): gate jobs/user admin ops and redact users in snapshot #14 dashboard auth; fix(kernel): checkpoint TTL evict race and wake loss on inject error #15 checkpoint evict race + wake loss) unchanged.
• Worker shell cleanup on TTL expiry is a separate follow-up (resource leak only).