feat(hybridcloud): Chain a strict drain into its mailbox's next claim

[vaind]

Stacked on #123265 (which stacks on #122893).

Problem

A strict provider's mailbox burns one claim per scheduler round trip. The gap between claims isn't the ~10s cycle cadence: under a wide backlog the mailbox competes with every other due head for each cycle's dispatch budget, so a deep strict mailbox can wait many cycles between drains. Re-discovery, not delivery, dominates its burn rate — and strict providers are precisely the ones lanes-style concurrent claims can't serve (see #122897's closing rationale).

Change

A drain that ends healthy with due work behind it dispatches the mailbox's next claim itself — _maybe_chain, gated by hybridcloud.webhookpayload.drain_chaining (default off). "Healthy with work behind" means exactly two endings:

• the drain consumed a claim that had filled the cap (the due prefix continues past it), or
• it released a tail at its soft-stop after delivering something — a drain that delivered nothing before the soft-stop spent its window in the queue, which is saturation, exactly when a chain would add queue load.

Never after a failure-stop or a lapse; backoff and the scheduler own those.

Why strict-only: the absolute-head gate admits one claim at a time, so a chain stays a single lineage per mailbox. A skip-on-failure provider in due-head mode would have the scheduler start a fresh claim behind every in-flight chain — one new self-sustaining pipeline per cycle, unbounded lanes.

Safety: the chain claims under the same drain lock and due-gate as every other dispatcher, so losing the race to a scheduler or push dispatch just continues the lineage under their attribution. chain_depth rides the task args as a runaway backstop (MAX_CHAIN_DEPTH), far above what a healthy chain reaches — each link is bounded by its own claim, and the chain ends at the first short claim. A chain failure is swallowed: the drain's work is already delivered, and the scheduler covers the mailbox.

Observability and rollout

Chain dispatches land in the existing dispatch / dispatch.claimed metrics as dispatcher:chain. Enable the option only after this deploy settles — chain_depth is only sent on chained dispatches, so workers from the previous deploy never see the new argument. Turning the option off stops new links immediately; in-flight ones drain out.