fleetd #176: subtract the lead's own subscription seat from free

maxLoad counted panes, never subscription seats: a subscription:true
profile's lead is itself a live claude session on that same account,
so free overstated capacity by the lead's own seat (measured free:1
with a real ceiling of 0, and free:3 on an idle fleet with a real
ceiling of 2).

Add FleetMcp.LeadSeatSource (same shape as QuarantineSource/
OutageSource) and Fleetd.leadSeatLookup, which derives the seat count
from fleet.leaders.<name>.profile matched against the target profile
by effectiveCredentialId() - no hardcoded "-1", and no new config key:
profile: already exists for this exact "which account does this lead
share" question. maxLoad itself is left untouched; only free (and a
new, additive-only leadSeats field) changes.

Exhaustion quarantine (cause 2 in the ticket) already forced free to 0
via the same BackendQuarantine capacityView already reads - confirmed
by reading the exhaustionSink wiring, no code change needed there.

fleetd/fleetd.example.yaml

@@ -306,6 +306,15 @@ profiles:
     #   GOTCHA 2 — `maxLoad` is the ONLY throttle you have here. There is no metering, no budget
     #   and no refusal on cost; the cap on live members is the single thing standing between a
     #   fan-out and your monthly limit. Set it deliberately and keep it small.
+    #
+    #   GOTCHA 3 (fleetd #176) — `maxLoad` counts members, never the lead itself. The lead is a live
+    #   `claude` session on this SAME account (a lead is never moved off-subscription, whatever its
+    #   own profile says), so it already holds one seat before any member spawns. If a lead's
+    #   `fleet.leaders.<name>.profile` names THIS profile (or one sharing its `credentialId`),
+    #   `fleet_list`'s `free` for this profile subtracts that lead's live seat(s) automatically — see
+    #   `profile:` under THE FLEET below. If no lead entry names this profile, fleetd has no way to
+    #   know it shares this account, and `free` will overstate what a fresh `fleet_spawn` actually
+    #   gets by exactly the seats the lead is quietly holding.
     # gitTokenEnv: GITEA_TOKEN        # opt-in: let this profile's workers open their own PR (CB-302)
     # gitHostEnv: GITEA_HOST          # defaults to GITEA_HOST; injected only with gitTokenEnv
     # exhaustedPattern: "usage limit has been reached"   # opt-in: classify a usage-limit refusal (CB-578)
@@ -503,6 +512,17 @@ fleet:
   # recognised: give it a `profile:` and the daemon launches the shortfall when fewer than
   # `instances` are live. Omit `profile:` and it is recognise-only, as before.
   #
+  # `profile:` has a SECOND job as of fleetd #176, even for a recognise-only lead you never want
+  # auto-launched: it is also how fleetd learns which account this lead's own session shares. A
+  # `subscription: true` profile bills the operator's Claude account, and the lead itself is always
+  # a live `claude` session on that same account — `maxLoad` never counted that seat. If a lead
+  # entry here names a profile (or one sharing its `credentialId`) that matches a worker profile,
+  # `fleet_list`'s `free` for that worker profile subtracts the lead's live seat(s) automatically.
+  # Setting `profile:` on an already-running, recognise-only lead is safe — the daemon only launches
+  # the SHORTFALL below `instances`, so naming a profile here does not, by itself, start anything.
+  # Omit it and fleetd has no way to derive the sharing — there is no other reliable signal on the
+  # daemon's side — so that lead's seat goes uncounted, exactly as before this ticket.
+  #
   # `tab:` (CB-579) is REQUIRED and is the only field identity depends on — the exact label of the
   # tab hosting the lead, matched case-insensitively. Label the tab yourself and put that same
   # string here, and the pane is recognised on the next rescan. Reopen the tab later, or the session