fix(ci): accept 204 from the o11y deploy-event route

[demtario]

Context

The three deploy-event steps in master.yml checked for 200, but POST /telemetry/deploy answers 204 on success (respondIngested in runner/workers/o11y/src/normalise/respond.ts returns new Response(null, { status: 204 }) after the event is written to the inbox). Run 36553451764 therefore emitted a false did not return 200 (204) warning for handsontable-demos-o11y and handsontable-demos-api. The steps now treat 204 (and 200) as success and warn on anything else; the docs note the real success code. Separately, the same run's handsontable-demos-authoring step got 405 because the /telemetry/* route was not attached yet on that first deploy; that is a real miss and is deliberately not touched here.

Types of changes

• New example
• Update to an existing example
• README / documentation change
• Demo runner (runner/) change
• CI / tooling change

How was this verified?

Read the handler (handleDeploy -> inboxWriter.ingest -> respondIngested -> 204) and the run logs for 36553451764 (deploy-o11y and deploy-api both logged deploy-event response: 204, deploy-authoring logged 405). actionlint on the workflows is clean. No worker code changed, so no runner tests are affected; pipeline/o11y-routes.test.mjs already asserts any 2xx for this route.

Checklist

• New/renamed example: added to runner/config/frameworks.json (see CONTRIBUTING.md); otherwise it won't appear on demos.handsontable.com (n/a, no example changed)
• New example: added a row to the tables in README.md (n/a)
• Ran pnpm build (and pnpm dev) in the affected example/server-example locally (n/a, workflow and docs only)

Related issue(s):

1. Follow-up to feat(runner): self-hosted observability on Cloudflare (ADR-0041, ADR-0042) #371

---

Note

Low Risk
Workflow and documentation only; no runtime or auth changes—just correct HTTP success checks for deploy telemetry reporting.

Overview
Aligns master deploy jobs with the real POST /telemetry/deploy contract: success is 204 from respondIngested, but the three post-deploy “report deploy to o11y” steps in master.yml only treated 200 as OK, so successful runs logged false warnings (e.g. did not return 200 (204)).

Each step now accepts 204 or 200 and warns on any other status; runner/docs/run-and-deploy.md documents 204 as the success code for that optional, non-failing reporting step.

^{Reviewed by Cursor Bugbot for commit c3090c7. Bugbot is set up for automated code reviews on this repo. Configure here.}