[FEAT] Master lock: deterministic exactly-one-master check

[haimbj1]

Why

The start ritual told a new master to check its own task list for a running Monitor. A task list only shows the session's OWN tasks. It can never see another session's Monitor. So the check passed exactly when it must not, and two masters could double-post to GitHub.

What

• New master_watch.py: the Monitor command. It takes an flock on <dataDir>/master.lock before it loops, then prints pending requests (via pending_requests.py) on change.
• A second master's arm attempt is REFUSED with the holder pid and instructions. No self-reporting.
• The kernel releases an flock when the holder dies — kill -9 and reboot included. A stale lock file never blocks; its pid content is diagnostics only.
• --probe tries the lock, reports, releases.
• SKILL.md ritual: the task-list check is replaced by the lock, plus a ListAgents cross-check (a live session that claims the master role means ask the human first).
• ms_master.sh / rotate_master.sh ritual prompts updated to match.
• Tests: acquire, refuse-while-held (cross-process), stale-file-never-blocks, release-on-exit. Added to CI.