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/branch-policy.yml	check-source-branch	10 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/.

[rubenvdlinde]

Note on this repo's main — every reusable-workflow caller is dead

Independent of this PR: all 8 reusable-workflow callers on launchpad's main point at Conduction/.github, an org that does not exist. development correctly uses ConductionNL/.github. Every one of them is a startup_failure — the tell is that the run's name renders as the raw path (.github/workflows/branch-protection.yml) instead of its name:.

Affected on main: branch-protection.yml, code-quality.yml, documentation.yml, openspec-sync.yml, issue-triage.yml, release-beta.yml, release-stable.yml, sync-to-beta.yml. That includes release-stable.yml, so stable releases cut from main are not running either.

Proven pre-existing on the base SHA: control PR #35 (tree byte-identical to main) produced the same startup_failure — run 30818608587 (branch-protection) and 30818608813 (code-quality). Introduced by commit 44ca6620, "ci(launchpad): point reusable workflows at Conduction/.github (org rename)".

Deliberately not fixed here — this PR is verified as additions-only and confined to job timeouts, and an org-ref correction is a separate, differently-risky change. Flagging it for a follow-up.

The job this PR does bound, check-source-branch, is launchpad's own inline workflow and is unaffected: it passed in 3s on this PR under the new 10-minute bound.

[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.