fix(api): ?branch= silently hid nearly every workflow run #5600

GET .../actions/runs?branch=main returned one run from four days earlier while the same endpoint unfiltered showed six from the last hour.

Two writers, two formats, one column

workflow_runs.ref holds both forms:

Both list endpoints normalised the query to one form and compared against it. That's the obvious implementation, and it excluded every push-triggered run — nearly all of them. The pre-existing per-workflow list had the bug too; the repo-wide one I shipped an hour ago inherited it by copying the approach.

Both now match either stored form. That works on the data that exists rather than the data we wish existed — historical rows carry both formats, and no migration can be retroactive about intent.

The part worth naming

The failure was a filter returning a plausible-looking short list, not an error. Nobody checks a short list.

It was found only by comparing filtered and unfiltered output side by side while chasing something else — and it had shipped and merged an hour earlier with tests that asserted the normalisation was correct. Those tests tested the implementation's idea of the column instead of the column.

The write side is deliberately not fixed here

Both bare-writing call sites now carry a note pointing at the readers that must match both forms, and saying not to tidy one format away without converting existing rows and auditing every reader — run.ref is fed back into enqueue and checkout paths.

A half-migration here would be worse than the divergence. The divergence is survivable and now handled; a half-migration would be neither.