ci: bound every CI job with timeout-minutes

[rubenvdlinde]

What

Adds timeout-minutes to all 7 CI jobs. Every job previously ran unbounded, so a hung runner (network stall, wedged docker build, a step waiting on input) burns the full 6-hour GitHub default before the run fails.

Values — measured, not guessed

Sized from observed fleet-wide durations across the ExApp sidecar wrappers (successful + failed executions; skipped runs excluded).

File	Job	Set	Observed
pull-request-lint-check.yaml	lint-check	15	n=176, median 0.6 min, max 1.4 min
pull-request-from-branch-check.yaml	check-branch	10	n=123, max 0.1 min
push-development-to-beta.yaml	create-pr	20	n=152, max 5.6 min
beta-release.yaml	release-management	45	n=26, max 0.7 min
unstable-release.yaml	release-management	45	n=26, max 0.7 min
release-workflow.yaml	release-management	45	n=26, max 0.7 min
build-exapp.yaml	build	30	no observed runs (docker build)

The release jobs are bounded at 45 rather than near their observed max because a spurious release failure is expensive, and to match the shared release jobs elsewhere in the fleet.

Bounds are deliberately loose. A timeout that fires under normal runner contention is worse than no timeout at all: it converts a slow run into a phantom defect that someone then has to investigate.

Verification

• Each touched file re-parsed with yaml.safe_load; the job set is byte-for-byte unchanged from the base branch.
• Each job asserted to carry exactly the value in the table (positive control), and the same probe run against the base SHA still reports None (negative control) — so the probe distinguishes bounded from unbounded rather than emitting a constant.
• 7 of 7 jobs bounded in this repo.
• Diff is workflow files only, additions only (2 added lines per file, 0 removed).
• Edits made by hand, not by any scripted rewrite.