fix(push): advertise a valid Largest for the push-mode catalog

[santi-ferreiro]

Problem

In push mode the catalog's PUBLISH advertised LARGEST_OBJECT = {0,0} while a stale refresh deadline simultaneously replaced the retained group. A first viewer's relative Joining FETCH then resolved against an extent covering nothing
retained, so the relay rejected it (0x3) and MSF-01 §5 catalog bootstrap failed with 0x1200 until a page reload.

Latent since moq-playa began enforcing MSF-01 §5 retrieval. Not player-specific — any conforming client
issues the mandated joining FETCH and needs a Largest to compute the range. The publisher was announcing a track without ever saying where its live edge was.

Changes

• track_install_retained merges the installed group into the track's largest-location history. Installing a retained group asserts those objects exist at those Locations, so history must advance exactly as a live write does; otherwise a later PUBLISH omits LARGEST_OBJECT. track_hist_merge was already on all three delivery paths and only missing here.
• The catalog's PUBLISH moves below moq_pub_set_retained_group, so it advertises an extent that already exists. Same hook cycle, before the flushing moq_pub_tick — no added latency.
• sender_republish_catalog tracks catalog demand across passes and re-arms the refresh clock on a false→true edge. The deadline was armed at install but the refresh gate also required demand, so with no subscriber it went stale and the first cycle bringing demand fired an instantly-overdue refresh in the same cycle that pushed the initial catalog live — replacing retained group 0 with a byte-identical group 1.

Behavior change to note in review

The catalog is now the last PUBLISH rather than the first, so derived track aliases shift (catalog 1 → 3 in a two-media-track stream). Aliases are arbitrary identifiers, but it is protocol-visible. pacing_reset_partial_fanout asserted
the old order and the old "no PUBLISH carries a Largest" invariant; both expectations are updated, the latter made per-entry since the catalog is now the sole exception.

The other three test changes are unrelated to this behavior: those suites read pr->track_name (a borrowed span) after moq_session_accept_publish, an advancing call that invalidates borrows — always undefined, and only working
while the catalog happened to be the first PUBLISH processed. The reorder exposed it rather than caused it.

Verification

148/148 on this base. End-to-end OBS → moqx relay → moq-playa: catalog resolves
on first load, no reload.

---

This change is 

[rwl4]

Thanks for the contribution. I’ve integrated it into a spec-grounded, rigorously tested fix.