chore: install toolchain, wire lint, add local deploy path

Answers four questions and starts build step 1.

Q22 — the scoped deploy user does not exist: aws iam get-user returns
NoSuchEntity. Recorded in §7 as NOT PROVISIONED and swept so that no file
describes it as existing. §10 records that user/pouya, the broadly-
permissioned personal user that has been authenticating to this account,
must never be used in CI; scripts/deploy-local.sh refuses to run as it.

Q23 — the Gitea instance reports 1.27.2, well above the vars-context floor,
so the first-step guard is belt-and-braces rather than load-bearing. What
remains is not a fact but a dependency: the instance is jointly administered,
so enabling Actions and registering a runner both need a second admin. Hence
npm run deploy (scripts/deploy-local.sh), which performs exactly what the
workflow performs — same guard, same three passes, same headers, same
invalidation. Documented as the current path, not as a workaround.

§10 gains the risk that follows: the deploy secret will live on jointly
administered infrastructure, where an instance admin can reach repo secrets.
That does not change the plan, but it makes the scoped IAM policy the actual
control between a shared Gitea instance and an AWS account holding another
business's client-database backups. Never widen it.

Q27 — response time is two business days, in site.ts with a derived short
form so the confirmation email cannot drift from the page.
Q28 — OBA sections confirmed, stamped "for now"; membership renews yearly,
tracked as R10.

Build step 1: dependencies installed and package-lock.json created, closing
the npm ci blocker. ESLint flat config and Prettier config added; npm run
lint, check and build all pass. Prettier deliberately excludes *.md and
tokens.css — reasons recorded in .prettierignore.

npm audit reports 7 high-severity advisories, all requiring an Astro major
upgrade. Not applied; escalated in AGENTS.md entry (s) as a decision.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012XquaEq4BgWMCwUqLEyNkF

docs/05-backend-spec.md

@@ -106,9 +106,14 @@ personal information only as long as necessary. Whatever number ships must match
 SES on submission:
 
 - **To Pouya:** the full submission, plainly formatted, replyable to the inquirer.
-- **To the inquirer:** confirmation of receipt, expected response time, a repeat
-  of the no-retainer language, and a link to the privacy policy. This email is
-  the reason the form beats a `mailto:` link.
+- **To the inquirer:** confirmation of receipt, the response-time commitment, a
+  repeat of the no-retainer language, and a link to the privacy policy. This
+  email is the reason the form beats a `mailto:` link.
+
+  **The response time is a public commitment — two business days** (§4,
+  Q27). Render it from `SITE.responseTime` / `SITE.responseTimeShort` in
+  `src/data/site.ts`; never retype it. It must read identically here, on
+  `/contact/`, and in any bio.
 
 **SES production access is granted** (Q19, 2026-08-26) — mail reaches unverified
 recipients, so the inquirer confirmation works. See §7 for the account state.

docs/06-deployment.md

@@ -26,10 +26,30 @@ DNS is at **Namecheap, not Route 53** `[verified 2026-08-25]`. Nothing in the
 pipeline touches DNS. Certificate renewal is ACM-automatic as long as the
 validation CNAME stays in place at Namecheap — **do not delete it.**
 
+## Today, deploys run locally
+
+**`npm run deploy`** (`scripts/deploy-local.sh`) is the current path. It runs
+the same guard, the same three sync passes in the same order with the same
+cache headers, and the same invalidation as the workflow — at this scale the
+pipeline changes only **how a deploy is triggered**, not what it does. Treat the
+script and the workflow as one artefact in two places: change one, change both.
+
+Two things block the workflow, and neither is a fact to look up:
+
+- **`adr-sml-deploy` does not exist** — `aws iam get-user` returns
+  `NoSuchEntity` (§7, Q22). Create it from *Create the user* below.
+- **Actions are not enabled and no runner is registered** (Q23). The Gitea
+  instance is jointly administered, so both need its second administrator.
+
+The script **refuses to run as `user/pouya`** — the broadly-permissioned
+personal user that has been authenticating to this account. See §10.
+
 ## CI runs on Gitea, not GitHub
 
-`AGENTS.md` D3 as amended, 2026-08-26: self-hosted **Gitea**, repo `adr-sml`,
-local clone at `/Users/pouya/Dev/Websites/adr-sml`.
+`AGENTS.md` D3 as amended, 2026-08-26: self-hosted **Gitea**. The instance,
+version, and repository are recorded in §7 — the version is comfortably above
+the floor for the `vars` context, so the first-step guard is belt-and-braces
+rather than load-bearing.
 
 **The live pipeline is `.gitea/workflows/deploy.yml`.** Gitea Actions speaks
 GitHub Actions syntax, so it is a near-direct port — the build steps, the
@@ -276,17 +296,18 @@ invalidation paths are a reliable source of confusing bugs.
 `main` is production; a push to `main` is what triggers a deploy. Work on
 short-lived branches, open a PR, merge.
 
-**The pipeline has never completed a run.** There is no `package-lock.json`, so
-`npm ci` exits at step one; `src/pages/` is empty, so there is nothing to build;
-and no record exists of an `act_runner` being registered. Treat "every push
-deploys" as the design, not as current behaviour.
+**The CI pipeline has never run.** Not for want of a lockfile — `npm ci`,
+`astro check` and `astro build` all work now — but because the deploy user does
+not exist (Q22) and Actions are not enabled with a runner registered (Q23).
+Treat "every push deploys" as the design; today the path is `npm run deploy`.
 
 **Pull request checks — planned, not implemented:** `npm run build` ·
 `astro check` · lint · Lighthouse CI against the budgets in `04-seo-spec.md` ·
 link check. `.gitea/workflows/deploy.yml` has **no `pull_request` trigger**
-(only `push` on `main` and `workflow_dispatch`), and neither `npm run lint` nor
-`npm run lighthouse` is wired — there is no ESLint config and no `lighthouserc`.
-Nothing gates a merge today.
+(only `push` on `main` and `workflow_dispatch`), so nothing gates a merge today.
+`npm run build`, `npm run check` and `npm run lint` all run clean locally;
+`npm run lighthouse` still has no `lighthouserc` and nothing to measure until
+pages exist.
 
 Tag every production deploy `v<year>.<n>` so a rollback has something to name.