Simplify CI workflow structure

Design CI/CD workflows to be simple, DRY, and correctly ordered. Specifically:

1. Avoid duplicating the same sequence of steps across multiple jobs; extract shared logic into a composite action (or reusable workflow) so changes only need to be made in one place.
2. Only add steps that meaningfully contribute to the workflow’s goal — e.g., don’t add a “check-only” tool (like a linter that can’t autofix) into an autofix job; it belongs in a verification job instead.
3. Prefer unconditional, always-run checks over complex path-based or conditional triggers when the check is cheap to run. Fragile file-path filters are hard to maintain and risk silently skipping checks when new files are added; simplicity and safety outweigh the minor cost of running the job every time.
4. Respect step ordering/dependencies: steps that generate code or artifacts required by later steps (e.g., npm run denoify) must run before the steps that depend on them (e.g., npm test).

Example — extracting duplicated steps into a composite action instead of repeating them in four separate jobs:

# .github/actions/perf-measure-type-check/action.yml
runs:
  using: "composite"
  steps:
    - run: bun scripts/generate-app.ts
      shell: bash
    - run: bun tsc -p tsconfig.build.json --diagnostics | bun scripts/process-results.ts > diagnostics.json
      shell: bash

Then each job simply calls uses: ./.github/actions/perf-measure-type-check instead of repeating the same steps.