Single poller per Telegram token, and an honest return on a dropped send

Three defects in the same neighbourhood, all of the same kind: courier reporting that something happened which did not.

1. Every leader-mode courier started its own Telegram poller. Telegram permits exactly ONE getUpdates consumer per bot token, so N concurrent sessions meant N pollers and a continuous 409 stream (three measured concurrently on 2026-08-04, one parented by a session alive since Jul 23).

   New (courier claim): a filesystem claim scoped to a hash of the token and
   to the relay dir. The claim is a SYMLINK whose target is the owner's pid,
   so it is created atomically with its owner already recorded -- a
   mkdir-plus-pidfile lock has a window where a SIGKILLed holder leaves an
   ownerless claim nobody can ever attribute or safely break. sigil's
   make-symlink swallows EEXIST (measured), so the win/lose verdict is read
   back from the link rather than taken from the call.

   Stale claims are breakable: pid-liveness answers 'alive, 'dead or
   'undetermined, never conflating "the owner is gone" with "I could not
   ask". Each tier carries its own positive control, and a live pid whose
   comm does not match ours is treated as a recycled pid, not a live owner.

   Losing the claim is normal and logged at info. The instance runs on as a
   full MCP server: tools, relays, sends, notifications. No retry, no exit.

2. The dry-run path returned "Message sent." byte-for-byte. Every gagged send from 2026-07-06 to 2026-08-04 reported delivery it had not earned, and mimicked the silent-drop bug it was masking so exactly that production observation of that bug was impossible while the gag was set.

   It now returns a string that cannot be read as success, and does not
   raise (an MCP error invites the retry loop behind the send storm). It
   also RELEASES the dedup key, because a dry-run is a definite
   non-delivery: without that, the next real send of the same text hit the
   suppress path and reported success while delivering nothing. Measured on
   the pre-fix binary: gag on, gag off, same text -> 0 deliveries,
   "Message sent.". Fixed: 1 delivery.

   The suppress path now says which of the two things happened rather than
   reusing the plain success string.

3. Concurrent leader instances shared one courier.log. Append is emulated (read, truncate, write back), so two instances zero-filled each other's file; the resulting NUL bytes made grep report zero matches on a pattern tail showed plainly, mid-incident. Leader mode now writes courier-<pid>.log, keeping the ten newest. The --log path is deliberately untouched: claude-ops passes an already-unique per-task path there and reads it back by name.

Verification is behavioural throughout. repro/repro-single-poller.sh runs two real couriers against the mock; mock_telegram.py now models Telegram's single-consumer 409, because the previous mock could not produce the error the fix removes and "zero 409s" would have passed for free. The pre-fix binary produces 4 conflicts and 2 poller children in the same window where the fixed binary produces 0 and 1. Run against the pre-fix binary the harness turns 17 assertions red.

The storm repro keeps 1 send -> 1 delivery and gains an always-on positive control: the same binary with only the dedup WINDOW neutered delivers 4, proving the counter can see duplicates. A pre-dedup control binary cannot be built on the current toolchain (SGB v10 bundle, v9 runtime) and reported 0 deliveries because it never started -- which would have read as a result.

Suite 105 passed / 0 failed (baseline 82/0).