Cursor: legacy harness install and user-profile sync deadlock on shared install-state.json

[solomonneas]

Found while landing #467 (issue #438 slice 2).

Problem

brigade harness install cursor --scope user (legacy, cursor_user_cmd.py) and brigade harness sync --target cursor --scope user (profile layer, harness_profile_cmd.py) both use ~/.cursor/brigade/install-state.json as their ownership state file, with incompatible schemas:

• legacy writes {"version": 1, "files": ..., "hooks": ..., "mcp": ...}
• the profile layer requires schema_version: 2 with workspace/harness keys

Each side refuses the other's state as a conflict and neither offers a recovery path:

• After a legacy install, harness sync --target cursor fails with unsupported ownership state version: None (the legacy file has no schema_version key) and writes nothing.
• After a profile sync, legacy harness install cursor reports unsupported ownership state version: 2 and skips all writes.

The only way out is manually deleting ~/.cursor/brigade/install-state.json, which also destroys the ownership attestations uninstall depends on.

Expected

One of:

1. The profile sync detects a version-1 legacy state and migrates/supersedes it deliberately (the legacy installer is documented as superseded by sync in --help), or
2. The two surfaces use distinct state filenames so they can coexist, or
3. At minimum, the conflict detail names the recovery step (rm ~/.cursor/brigade/install-state.json after brigade harness uninstall from the owning surface) instead of a bare version error.

Repro

HOME=$(mktemp -d) brigade harness install cursor --scope user --write
HOME=<same> brigade harness sync --target cursor --scope user --workspace . --write
# -> conflict: unsupported ownership state version: None; nothing written

Notes

• Safe today: both directions fail closed (conflict, no clobber), so this is a UX/migration bug, not data loss.
• --adopt does not cover ownership-state conflicts, only instruction/MCP surfaces.