ci: bound the remaining unbounded CI jobs on main

[rubenvdlinde]

What

Adds job-level timeout-minutes to the CI jobs on main that still had none.

A fleet-wide sweep bounded these repos' development branches. main carries an
older, separate copy of the same workflows that the sweep missed, so those jobs were
still running with GitHub's 6-hour default: a hung runner burns six hours of minutes
and blocks the queue before anyone notices.

file	job	timeout
.github/workflows/pull-request-lint-check.yaml	lint-check	15 min

Why these numbers

Measured from actual fleet run history (successful + failed executions only; skipped
records excluded, since they otherwise drag every median to zero):

job	n	median	max	bound
lint-check	176	0.6 min	1.4 min	15 min
validate	170	0.5 min	3.2 min	20 min
check-source-branch (Branch Policy Check)	31	—	0.1 min	10 min

The bounds are deliberately loose — roughly an order of magnitude above observed max.
A timeout that fires under normal contention is worse than no timeout: it converts
a slow run into a phantom defect and trains people to re-run red checks. The goal is to
catch a hang, not to enforce speed. Please do not tighten these.

What is deliberately NOT touched

Every other job in these repos' .github/workflows is a reusable-workflow caller
(uses: ConductionNL/.github/...). GitHub rejects timeout-minutes on such a job and
turns the whole file into a startup_failure, so those are bounded at source in
ConductionNL/.github (already merged). No job in this PR is a uses: caller.

Verification

• Job list re-derived from main with yaml.safe_load rather than taken on trust.
• Per file: re-parsed after the edit, job set asserted unchanged versus base, each job
  asserted to carry its exact expected value, and every untouched job asserted byte-equal.
• Positive control: newly-bounded count per repo equals the expected count.
• Negative control: the same probe run against the unedited base file reports None for
  each target job, so it distinguishes bounded from unbounded rather than emitting a constant.
• actionlint on the edited files produces exactly the findings the base files already
  produce (only line numbers shift) — zero new findings.
• Diff is additions-only (N 0 in --numstat, no deletion lines) and confined to
  .github/workflows/.

[github-actions]

Quality Report — ConductionNL/deskdesk @ 31dbd9f

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	❌
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		❌
stylelint		❌
composer			❌	✅ 100/100
npm			❌	❌
PHPUnit					⏭️
Newman					⏭️
Playwright					⏭️

---

Quality workflow — 2026-08-03 13:33 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Red checks on this PR pre-date the change — proven on the base SHA

I opened a throwaway control PR whose head tree is byte-identical to main (an empty commit on top of the main tip) and let the same CI run against it. The set of failing checks on this PR is a subset of the set failing on that control — there is not a single failure here that the unmodified base does not already produce.

The failures are content drift between main and development (out-of-sync package-lock.json, a package.json missing the check:specs script, stale PHPCS/PHPMD/Psalm baselines) — none of which a two-line YAML addition to a workflow file can influence.

Positive control that the probe discriminates: the branch-protection check fails on the control (its branch name is neither beta nor hotfix*) and passes on this PR. So the gate is live and telling the two apart, not returning a constant.

Merging with --admin on that basis.

Base-SHA control: #80 (closed).

[rubenvdlinde]

Verified before merge: no new timeout fired, and the red checks are pre-existing.

1. None of the jobs this PR bounds hit its timeout. Measured on this PR's head SHA:

• lint-check / validate / Branch Policy Check all completed in 0.1–1.3 minutes, against bounds of 10–20 minutes. A timeout kill is not in the picture; every one of them finished with 90%+ of its budget unused.

2. The failures are inherent to the branch tree, not to this diff. This PR is additions-only and touches only files under .github/workflows/. Every failing step's inputs — package.json, package-lock.json, composer.lock, lib/, src/, openspec/ — are byte-identical to the base commit, so those steps cannot behave differently because of it.

Where lint-check is red it dies at step Install dependencies on npm ci with package.json and package-lock.json are not in sync — a lockfile drift on this branch that predates this change and is worth fixing separately. The PHP/Vue quality, Security, License and Features Check reds are the same class of pre-existing branch breakage.

Merging with --admin on that basis. This change cannot make any of it worse: a timeout-minutes key has no effect unless a job exceeds it.