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

README.md

@@ -22,9 +22,10 @@ npm run dev        # http://localhost:4321
 | `npm run build` | Static build to `./dist` |
 | `npm run preview` | Serve the built site locally |
 | `npm run check` | `astro check` — type and template errors |
-| `npm run lint` | ESLint + Prettier check — **not yet wired**, no ESLint config exists |
+| `npm run lint` | ESLint + Prettier check |
 | `npm run format` | Prettier — rewrite files in place |
-| `npm run lighthouse` | Lighthouse CI — **not yet wired**, no `lighthouserc` exists |
+| `npm run lighthouse` | Lighthouse CI — **not yet wired**; nothing to measure until pages exist |
+| `npm run deploy` | Build and deploy from this machine — see Deployment |
 
 ## Before you contribute
 
@@ -49,19 +50,24 @@ Full protocol and prompt guidance: `docs/08-execution-protocol.md`.
 
 ## Deployment
 
-`.gitea/workflows/deploy.yml` is the deploy pipeline — **Gitea Actions**, not
-GitHub Actions. On a push to `main` it builds, syncs to S3, and invalidates
-CloudFront.
+**Today, deploys run locally: `npm run deploy`** (`scripts/deploy-local.sh`).
+It runs the same guard, the same three sync passes with the same cache headers,
+and the same invalidation as the CI workflow — at this scale the pipeline
+changes only *how* a deploy is triggered, not what it does. The script and
+`.gitea/workflows/deploy.yml` are one artefact in two places: change one, change
+both.
 
-**It has never run green.** There is no `package-lock.json`, so `npm ci` exits
-at step one; `src/pages/` is empty, so there is nothing to build; and whether an
-`act_runner` is registered is recorded nowhere. The workflow is written; the
-pipeline is unproven.
+`.gitea/workflows/deploy.yml` is the CI pipeline — **Gitea Actions**, not GitHub
+Actions. **It has never run**, for two reasons that are not oversights:
 
-The workflow's **first** step guards against the other way this fails quietly:
-it aborts the run, naming the variable, if `AWS_REGION`, `S3_BUCKET`, or
-`CLOUDFRONT_DISTRIBUTION_ID` is empty — which is how a Gitea too old for the
-`vars` context manifests.
+- The scoped IAM user does not exist. `aws iam get-user --user-name
+  adr-sml-deploy` returns `NoSuchEntity` (`AGENTS.md` Q22).
+- Actions are not enabled and no runner is registered. The Gitea instance is
+  jointly administered, so both need its second administrator (Q23).
+
+Its **first** step is a guard: the run aborts, naming what is missing, if any
+required variable or either AWS secret is empty. Only emptiness is tested and no
+value is echoed.
 
 The GitHub Actions equivalent, which uses OIDC role assumption, is kept as
 `docs/reference/github-actions-oidc.yml.example` in case the project ever moves
@@ -70,13 +76,14 @@ Gitea falls back to that directory when `.gitea/workflows` is absent, so a
 workflow file left there with a `push` trigger would be only conditionally
 inert. As an `.example` under `docs/` it cannot be picked up at all.
 
-**The pipeline is designed around a long-lived AWS credential.** Gitea is not an
-AWS OIDC provider, so there is no role to assume: deploys are to authenticate as
-a scoped IAM user, `adr-sml-deploy`, with its access key held in the
-repository's Gitea Actions secrets. Nothing in `AGENTS.md` records that user as
-created or that key as issued — `docs/06-deployment.md` is a procedure to
-perform, not a record of one performed. Two things are meant to bound the risk,
-and neither is confirmed in place:
+**The pipeline is designed around a long-lived AWS credential, and it does not
+exist yet.** Gitea is not an AWS OIDC provider, so there is no role to assume:
+deploys are *to* authenticate as a scoped IAM user, `adr-sml-deploy`, with its
+access key in the repository's Gitea Actions secrets. `aws iam get-user`
+confirms that user has not been created (Q22). In the meantime the local script
+**refuses to run as `user/pouya`**, the broadly-permissioned personal user —
+see `AGENTS.md` §10. Two things are meant to bound the risk, and neither is in
+place yet:
 
 - **The policy must stay narrow.** Four actions: `s3:ListBucket` on one bucket,
   `s3:PutObject` and `s3:DeleteObject` on that bucket's contents, and