fix(ci): move linter workflow into .github so GitHub actually runs it

[savvides]

Problem

4b96052 added the linting workflow at github/workflows/linter.yml — missing the leading dot — which left a stray top-level github/ directory sitting next to the real .github/:

$ git ls-tree main --name-only | grep -i github
.github
github          <-- this one

GitHub only reads workflows from .github/workflows/, so the workflow never ran.

Why it mattered

The job is correctly named run-lint, which is exactly the context the Protect Main Branch ruleset requires:

{ "type": "required_status_checks",
  "parameters": { "required_status_checks": [ { "context": "run-lint" } ] } }

A required check that can never report blocks merging forever. That is why the entire #72–#86 backlog sat at BLOCKED since Aug 22 and had to be merged with admin bypass.

Fix

git mv github/workflows/linter.yml .github/workflows/linter.yml, and remove the now-empty stray directory. The workflow content is unchanged — this is a pure rename.

Heads-up on what this turns on

Worth knowing before this lands, because it changes CI behaviour repo-wide:

• VALIDATE_ALL_CODEBASE: false lints only files changed in a PR. So this PR only exercises the YAML validator on the renamed file — it passing does not prove future PRs pass.
• No VALIDATE_* variable is set to true, which means super-linter enables every validator it can detect, rather than an opt-in subset.
• This repo has no linter config anywhere — no package.json, .eslintrc, .shellcheckrc, .markdownlint.json, pyproject.toml, or .editorconfig.

The practical effect is that the first PR to touch a shell script or a JS file gets linted by shellcheck/eslint defaults with no project config to soften them. If that turns out to be noisy, the fix is to pin the validator set explicitly (VALIDATE_GITHUB_ACTIONS: true, VALIDATE_JSON: true, …) rather than to unpin the required check again.

🤖 Generated with Claude Code