docs: a relative handoverPath lands in the LEAD's repo, not fleetd's (#491)

On this host the lead's cwd IS the fleetd checkout, so fleetd/.gitignore
protects the handover file and the distinction is invisible. On fleet01 the
lead works in /home/ltms/LTMS/kb while fleetd sits in a different directory,
and that repo has no .handover rule — measured 2026-09-12.

Tell the lead to check its own workspace's .gitignore before writing, and to
report it rather than committing the file or editing someone's .gitignore.

Refs fleetd #491, #487, #480.

.claude/skills/handover/SKILL.md

@@ -141,6 +141,14 @@ refused.**
    own workspace before it hands it to you. The daemon and your pane can run in different
    directories, so a path you resolve yourself can point at a different file from the one the daemon
    will check.
+
+   **Check that the path is ignored by git before you write to it (#491).** A relative
+   `handoverPath` resolves inside YOUR workspace, which is usually a repository — and usually not
+   the `fleetd` one, so an ignore rule added to `fleetd` does not protect it. Run
+   `grep -n handover <your workspace>/.gitignore`. No output means the file you are about to write
+   will show up as untracked content in that repo. The file is a snapshot of live state and must
+   never be committed, so tell the operator rather than committing it or silently editing their
+   `.gitignore`.
 2. **Write the handover file at that path**, following sections 1–10 above.
 3. **Ask the operator, then `fleet_handover{action: "confirm", token, operatorConfirmed: true}`.**