Fix Instatus fetcher schema rejects numeric maintenance duration (bluesky) - #2702

Root cause

• Symptom: Sentry alert FetchError: [instatus (bluesky)] schema mismatch: https://status.bsky.app/summary.json, 2 events (19:00:31Z, 19:10:23Z) from the external-status cron on openstatus-workflows.
• Trigger: Bluesky's "Network Maintenance" began at 18:45:00Z; the first event is the next cron tick. Zero events of this signature in the prior 30 days — the populated-maintenance branch had never been hit before.
• Mechanism: a live fetch confirmed summary.json returns HTTP 200 with valid Instatus JSON whose activeMaintenances[0].duration is the number 60. The schema declared duration: z.string().optional(); reproduced with zod 4.1.13 (the lockfile version): parse fails with invalid_type, expected string, received number at ['activeMaintenances', 0, 'duration'], which fetchJson rethrows as the FetchError of kind=schema.
• Root cause is in our schema, not the page: Instatus serves duration as a number on live pages, and the handler treats schema mismatch as an our-side defect (caught, last-known status kept, reported to Sentry). Impact is bounded to the directory display path; no customer monitor depends on this fetcher.
• Why this fixes it: the union accepts both wire shapes without transforming anything, and duration is never read downstream, so mapped output for every previously-parsing payload is identical. detect.ts reuses the same exported schema, so the detection probe also stops misclassifying live Instatus pages during maintenances.

Out of scope / follow-ups

• The remaining duration of Bluesky's maintenance window itself: the directory entry will show under_maintenance after this merges, which is the correct rendering of a real maintenance.
• Sentry alert-rule tuning for the external-status family (the connected token already 400s on alert-rule reads, tracked separately).

• Signal (alert): FetchError: [instatus (bluesky)] schema mismatch: https://status.bsky.app/summary.json
• Surfacing site: openstatus-workflows (Fly app) at apps/workflows external-status cron phase=status, reported to Sentry from openstatus-workflows (url tag http://openstatus-workflows.fly.dev/cron/external-status, tags cron:external-status, fetcher:instatus, slug:bluesky, handled:yes)
• Mechanism: The cron fetched https://status.bsky.app/summary.json, which returns HTTP 200 with valid Instatus JSON. Instatus's activeMaintenances[].duration is a JSON number (60), but instatusMaintenanceSchema in packages/status-fetcher/src/fetchers/instatus.ts declared duration: z.string().optional(). Zod 4.1.13 (the lockfile version) rejected the payload with invalid_type at path ['activeMaintenances', 0, 'duration'], which fetchJson rethrew as FetchError kind=schema: '[instatus (bluesky)] schema mismatch'.
• Producer: instatusMaintenanceSchema in packages/status-fetcher, executed by the external-status cron in apps/workflows on openstatus-workflows, instance openstatus-workflows (single Fly app, server_name 85e906a41411e8), tenant The OpenStatus external-services directory (its own dogfood dataset), entry slug 'bluesky', at openstatusHQ/openstatus:packages/status-fetcher/src/fetchers/instatus.ts#instatusMaintenanceSchema (line 28 pre-fix)
• Trigger: Bluesky's scheduled maintenance 'Network Maintenance' started at 2026-09-10T18:45:00.000Z, flipping page.status to UNDERMAINTENANCE and populating activeMaintenances. The 19:00:31Z event is the first cron tick after that moment; with no active maintenance before today, the fetcher had never hit the populated-maintenance branch.
• What happens to the failed unit today: The cron handler wraps every fetch in try/catch (handled=yes): a schema mismatch keeps the last-known status for the entry, increments a failure count, and reports a FetchError of kind=schema to Sentry. The unit is dropped for that tick and re-fetched on the next one; nothing retries within a tick and nothing dead-letters. The handler's own semantics treat a schema mismatch as an our-side defect.
• Cadence check: Confirmed: the ~10-minute cron explains the two events (19:00:31Z, 19:10:23Z). The 30-day window shows zero prior events of this signature, which the hypothesis predicts: the defect exists on every tick but only bites when a maintenance exposes the numeric field. The maintenance's stated duration is 60 minutes, so roughly six events would accrue without the fix.
• Blast radius: 0 other resource(s), 0 other tenant(s); data at risk: The external directory's status snapshot for any Instatus-hosted page goes stale while the page is under maintenance (last-known status kept, no refresh, no updated_at). Today it hit Bluesky; every other Instatus-hosted entry is one scheduled maintenance away from the same failure.
• Producer evidence:
  • Live fetch of https://status.bsky.app/summary.json: HTTP 200, page.status UNDERMAINTENANCE, activeMaintenances[0].duration = 60 (number) on entry 'Network Maintenance', status INPROGRESS, start 2026-09-10T18:45:00.000Z
  • Reproduced the parse failure in isolation with zod 4.1.13, the exact lockfile version: success false, issues [{code invalid_type, expected string, received number, path ['activeMaintenances', 0, 'duration']}]
  • packages/status-fetcher/src/fetchers/instatus.ts:28 (pre-fix) declared duration: z.string().optional(); one caller today, the external-status cron at apps/workflows/src/cron/external-status.ts, one directory entry (bluesky) on this fetcher; packages/status-fetcher/src/detect.ts:63 reuses the same schema for provider detection and benefits from the same fix
  • Sentry 30-day scan: exactly 2 events of this signature, timestamps 2026-09-10T19:00:31Z and 19:10:23Z, one per cron tick, first occurrence 15 minutes after the maintenance began

• packages/status-fetcher/__tests__/fetchers/instatus.test.ts: modified, +30/-0
• packages/status-fetcher/src/fetchers/instatus.ts: modified, +2/-1