Add rpa-bot-handoff skill: ops guide for bot handover

The skill scans a bot with subagents (never runs it) and writes
HANDOVER.md, an 11-section ops guide in the operator's order: where is
what, how to run, how long to wait, after the run, how to see an
exception, exception list, how you will know, how to tell us, don'ts,
issues seen before. Dev material (check against 12 failure classes from
Tebra Auto Post, gaps with file:line, incidents) goes to HANDOVER-DEV.md.

Also adds ADR-0004, glossary terms, five fixture bots and a handoff eval
runner (--resume, --regrade) with results from 47 runs of the earlier
13-section version. The grader still expects that structure and must be
updated before the next eval run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

tests/evals/results/handoff/h-api-sync-screens-r1.json

@@ -0,0 +1,31 @@
+{
+  "case": "h-api-sync/screens",
+  "rep": 1,
+  "passed": true,
+  "checks": {
+    "HANDOVER.md written": true,
+    "no other file changed": true,
+    "bot never run": true,
+    "no placeholders left": true,
+    "13 sections in order": true,
+    "used subagents": true,
+    "every status listed": true,
+    "catalogue: 4+ complete rows": true,
+    "F1-F12 all accounted for": true,
+    "no code refs in ops sections": true,
+    "fix-before-handover has file refs": true,
+    "no secrets or personal data": true,
+    "where-to-look respects ops access": true,
+    "asks escalation": true,
+    "asks ops access": true,
+    "known incidents from history": true,
+    "misleading status flagged": true,
+    "retry limit": true,
+    "console-only crash output flagged": true
+  },
+  "cost_usd": 1.3940436000000003,
+  "subagents": 2,
+  "work_dir": "C:\\Users\\ec10866\\AppData\\Local\\Temp\\handoff-h-api-sync-screens-8tutneru\\project",
+  "reply": "I wrote `HANDOVER.md` in the repo root. I read the code and git history only; the bot was not run and no code was changed. The verification was done by reading through the doc, so it's not a test of the bot.\n\n| Item | Result |\n|---|---|\n| Sections | 13 |\n| Exceptions catalogued | 12 (E01\u2013E12) |\n| Failure classes | 11 covered, 1 not applicable (F2: the bot has no windows, it only calls a web service) |\n| Statuses | All 4 (Synced / Duplicate / Invalid / Failed) and all 9 message strings are covered |\n| PHI, keys, IPs | None in the doc; there are no file:line refs outside section 13 |\n\n**Your access answer vs the code:**\n- The bot has **no screens**. It is a background script that Task Scheduler starts every hour. So for ops, only `data/output/` is usable.\n- There **is** a log, `logs/sync.log`. I read your answer as \"ops cannot open it\" and did not point ops at it anywhere.\n\n**Most important \"Fix before handover\" items (17 in total):**\n1. The duplicate check before a retry has no error handling, so one network error crashes the whole run. That is the same symptom as the old 429 incident.\n2. The live billing API key is in `.env`, which is committed to git. It needs to be rotated.\n3. Nothing in the output folder shows whether a run finished or crashed. The \"run done\" line only goes to the log.\n4. A partial create (some lines rejected) still shows as \"Synced\".\n5. A wrong API key is retried 5 times on every invoice and gives no reason, so runs can overlap.\n6. The `data/output/` folder is not created by the code, so a fresh install crashes on every run.\n\nQUESTIONS: Escalation: who does ops call for a dev issue (team or role), and how (ticket, chat channel)? | Ops access: which of the bot's places can ops open - the app's screens, the output folder, the log folder, the database? | Unknowns: are there any statuses or exceptions whose meaning the code doesn't make clear?",
+  "stderr": ""
+}