ci: verify every pull request through one workflow

[CptSchnitz]

Adds .github/workflows/pull_request.yaml, reaching every check through
turbo's existing task vocabulary rather than beside it: lint, format,
type-check and lint:openapi share one matrixed job (each only differs
by task name), test gets its own job for the extra coverage step, and
chart lint gets its own job since it isn't a turbo task at all - it
wasn't an npm script in the manager's former repo either, just a
directly-invoked composite action.

Change detection compares against the pull request's base branch
(TURBO_SCM_BASE=origin/${{ github.base_ref }}), so a pull request
touching only the SDK schedules no tasks for the manager - verified
locally: editing only packages/jobnik-sdk marks the sdk and its
dependent e2e workspace affected, never jobnik-manager. The turbo
build cache (.turbo/) is restored via actions/cache, keyed on the
commit sha with an os-level fallback, so a later push in the same PR
reuses what an earlier one already built.

Node is set up from the repository's single declared version
(node-version-file: .nvmrc) in a new composite action
(.github/actions/init-pnpm), rather than a version pinned in the
workflow - the reference monorepo's workflow pins one directly and
disagrees with its own engines field.

Three checks the reference monorepo's pull-request workflow lacks are
carried over from the manager's own former workflow, per spec: the
format task, the type-check task, and a chart-lint job running the
existing MapColonies/shared-workflows helm-lint action against
apps/jobnik-manager. The manager's coverage reporting is preserved via
davelosert/vitest-coverage-report-action, gated on the manager's
coverage-summary.json actually existing so it doesn't fail a run where
the manager wasn't affected.

Third-party actions are pinned to major-version tags rather than
commit SHAs (unlike the reference monorepo's own actions), because
this repo has no way to verify a SHA is the one it claims to be
without network access to check; a wrong pin fails outright, so a tag
is the safer default here. Worth revisiting with SHA pins once that
can be verified.

Known, pre-existing issue surfaced while wiring in helm-lint-v1, left
as a comment in the workflow rather than fixed here (it's upstream,
in MapColonies/shared-workflows, not this repo): its own changed
output binds to a step id that doesn't exist (list-changed vs the
step's actual list_changed), so every if-gated step downstream of it
(ct lint, the kind cluster, ct install) never runs. The job currently
only verifies the chart's dependencies resolve, not that it lints
clean - carried over as-is from the manager's own former workflow,
which had the identical, apparently long-dormant gap.

Verified locally against this branch's own diff from master: lint,
format, type-check, lint:openapi and test all pass through
turbo run --affected. Also verified that a deliberately
introduced lint error, type error and failing test in the sdk each
fail their respective task (reverted after, not part of this commit).

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[github-actions]

Coverage Report for apps/jobnik-manager

Status	Category	Percentage	Covered / Total
🟢	Lines	100% (🎯 80%)	768 / 768
🟢	Statements	100% (🎯 80%)	785 / 785
🟢	Functions	100% (🎯 80%)	112 / 112
🟢	Branches	100% (🎯 80%)	219 / 219

File Coverage

No changed files found.

Generated in workflow #1 for commit 44dd02f by the Vitest Coverage Report Action