Define lock storage, ownership, and retention for workspace cleanup

[chubes4]

Problem

Workspace cleanup uses lock concepts but DMC does not make the lock storage/ownership/retention model obvious to operators. During cleanup work, the presence/question of lock directories made it unclear whether DMC is introducing more filesystem bloat while trying to remove workspace bloat.

Observed locally:

• /Users/chubes/Developer/.locks existed but was 0B.
• The operator had no clear CLI/status explanation for what lock directories are, when they are safe to remove, or whether stale locks are pruned.

Expected behavior

DMC should define and expose a clear lock lifecycle:

• Prefer database/action-scheduler locks where possible.
• If filesystem locks are required, keep them under a single documented DMC-owned path.
• Each lock records owner, run/job id, purpose, created_at, heartbeat/expiry, and stale-after.
• Stale locks are automatically pruned or surfaced through workspace hygiene.
• workspace cleanup status/evidence reports active locks for a run.
• No unbounded lock accumulation.

Acceptance criteria

• workspace hygiene reports lock directory path, count, and stale lock count.
• A safe workspace cleanup locks prune --dry-run or equivalent exists if filesystem locks remain.
• Docs/help explain the lock storage model.
• Locks do not become another hidden bloat source.

[chubes4]

This should be implemented under the same DB-source-of-truth umbrella as #245.

Preferred long-term shape:

• Use a DB-backed lock abstraction when possible; avoid filesystem lock directories as coordination state.
• Lock rows should include owner/job/run references, purpose, heartbeat, expiry, and bounded metadata.
• Cleanup apply/resume/cancel should use locks keyed by run_id and affected workspace scope.
• workspace hygiene should report active/stale lock counts and retention status.
• Retention should prune expired completed-run locks automatically.

If a filesystem lock is still needed for cross-process safety, it should be a thin OS-level guard with mirrored DB state for visibility and retention.