ci: models-snapshot, docs-update and stats are the remaining scheduled workflows without queue: max — a third arrival silently drops the pending run #156

Problem

Three scheduled workflows still use the default single-slot concurrency queue (queue: single is the implicit default when queue: is omitted). With cancel-in-progress: false, when one run is in progress and a second run arrives, the second becomes the single pending run — and a third arrival silently replaces/drops the pending run. This is the same defect fixed for the other scheduled workflows in #151 (close-issues / compliance-close) and #133 (close-prs); #151's title called those "the last scheduled workflows without queue: max", but three more remain:

Verified on current main by reading all three files, and run history confirms all three fire on schedule on this fork (e.g. models-snapshot run 39370182618, docs-update run 39361895418, stats run 39302250069 — all schedule events).

Why it matters

• A manually dispatched run (the way a maintainer forces a refresh) can silently drop a pending scheduled run, or vice versa — no error, no notification, the dropped run just never happens.
• Today the jobs in these three workflows are gated to the upstream repo (github.repository == 'anomalyco/opencode', and sst/opencode for docs-update), so on this fork the runs skip quickly and the collision window is small. But the flaw becomes fully live the moment any of these workflows is ungated or adapted for the fork — CI: models-snapshot workflow never runs on this fork — gated to upstream, targets nonexistent dev branch, bundled catalog already stale #109 already proposes exactly that for models-snapshot. Fixing the queue semantics now removes a silent-drop trap from that future work.
• Consistency: every other cancel-in-progress: false workflow in this repo now carries queue: max; these three are the remaining exceptions.

Suggested fix

Add queue: max to the concurrency block of models-snapshot.yml and docs-update.yml. For stats.yml, expand the string shorthand into block form preserving the same group and the current implicit cancel-in-progress: false, plus queue: max:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false
  queue: max

Note: queue: max must NOT be combined with cancel-in-progress: true (that combination is a workflow validation error — see developing-today-forks/openchamber#84); all three workflows here are false, so the combination is valid.

Acceptance criteria

• models-snapshot.yml, docs-update.yml, and stats.yml each declare queue: max with cancel-in-progress: false and their existing group expressions unchanged.
• All three files still parse as valid YAML and pass any workflow lint the repo runs.
• A repo-wide grep shows no remaining scheduled/workflow_dispatch workflow with cancel-in-progress: false (explicit or implicit) lacking queue: max.