feat(broker): gate broker advertisement on bundled fduty capability

[ysyneu]

What

The runner advertises broker=1 to safari only when both hold:

1. the build supports the broker (BrokerSupported — Linux), and
2. the bundled fduty is broker-capable (probed once via fduty version --json → broker_egress).

Why (rollout safety)

A broker-capable runner always advertised broker=1, which makes safari deliver the per-person app_key out-of-band (never in the bash env). But the runner does not refresh fduty on self-update, so a fleet runner can carry a stale, pre-broker fduty across a runner upgrade. That fduty can't read FLASHDUTY_CRED_FD → every authenticated call would fail.

Gating the advertisement on the bundled fduty's actual capability makes the rollout self-healing:

• stale fduty → no advertisement → safari uses the legacy env-key path → old fduty keeps working;
• once fduty updates → next reconnect advertises broker mode.

Works in zero-egress BYOC (no fduty refresh needed). Requires the companion cli change that adds broker_egress to fduty version --json (flashduty-cli#36).

How

• environment/broker_capability.go: BrokerEgressEnabled() = BrokerSupported AND a cached one-time fduty version --json probe. Any probe failure (missing/old fduty, non-JSON, nonzero exit) → "not capable" → safe fallback.
• ws/client.go: advertisement now gates on BrokerEgressEnabled().

Test

• Unit: TestProbeFdutyBrokerEgress (capable / missing-field / false / legacy-plain-text / nonzero-exit) + missing-binary case.
• e2e (real BYOC runner in a Linux container against a live backend):
  • new fduty → Safari logs broker=true → broker auth works (fduty whoami returns the real identity, zero app_key in container env);
  • legacy-fduty stub → Safari logs broker=false → env-key fallback still authenticates.

Follows flashduty-runner#56.