`pnpm run build` fails on a clean checkout: subgraph#build runs before the codegen it needs

## What happens

`pnpm run build` at the repo root fails on a clean checkout. Found while trying to
enable the build gate for #199 (`run-build: true`), which is exactly the command
pm-kit's CI would run.

```
$ pnpm install --frozen-lockfile
$ pnpm run build
...
subgraph:build: Error: The AssemblyScript compiler crashed when compiling this file: 'src/mapping.ts'
subgraph:build: ELIFECYCLE Command failed with exit code 1.
ERROR subgraph#build: command (.../apps/subgraph) pnpm run build exited (1)

Tasks: 0 successful, 2 total
Failed: subgraph#build
```

Tested on `8ac29bd`, Node 20.19.4, pnpm 8.10.0.

## Root cause

`apps/subgraph` runs `graph build`, which requires `graph codegen` to have written
`generated/` first — `generated/` is gitignored, so it never exists on a fresh clone.
`turbo.json` does not declare that dependency: the `build` task has
`dependsOn: ["^build"]` (upstream *packages*), and there is no `codegen` task at all,
so nothing orders codegen before build.

Confirmed by running the missing step by hand — after it, the same build succeeds:

```
$ pnpm --filter subgraph codegen
Types generated successfully
$ pnpm --filter subgraph build
Build completed: build/subgraph.yaml
```

So it is an ordering gap, not a broken mapping. `apps/subgraph/package.json:type-check`
already works around the same thing with `if [ -d generated ]; then ... else echo
'skipped' ...`, which is the workaround rather than the fix, and is why typecheck stays
green while build does not.

`pnpm --filter web build` passes on its own — the web app is unaffected.

## Impact

**One thing, and it is not CI.** `pnpm run build` is the documented way to build this
monorepo — it is in the root README and in `CLAUDE.md` — and it fails on a fresh clone.
A new contributor's first build errors out inside AssemblyScript with a message
suggesting they comment out `src/mapping.ts` line by line, for a subgraph they were
probably not touching.

`pnpm --filter web build` works, so anyone who already knows the layout routes around it.
That is what makes it a papercut rather than an outage — and also why it has survived.

## Suggested fix

Declare a `codegen` task in `turbo.json` with `generated/**` as its output, and make
`subgraph#build` depend on it. Turbo then caches codegen instead of re-running it per
build. `apps/subgraph`'s `type-check` script currently works around the same gap with a
shell guard (`if [ -d generated ]; then ... else echo 'skipped'`) — that guard is the
symptom, and it can go once the ordering is expressed properly.

## Acceptance

- [ ] `pnpm run build` succeeds on a clean checkout (`git clean -xdf` + `pnpm install`)
- [ ] The codegen -> build ordering lives in `turbo.json`, not in a shell guard
- [ ] `apps/subgraph`'s `type-check` guard removed, since it exists only to work around this

## Correction: this does NOT block the CI build gate

I originally filed this claiming it blocked #199's `run-build: true` checkbox. **That was
wrong, and the checkbox itself was wrong.** The org-wide decision on the pm-kit baseline
is that **Vercel builds and CI is the correctness gate** — every deploy-elsewhere repo
sets `run-build: false` (`mondeto-admin`, `mini-quiz`, `askbots`); only `saluto`, which
has no platform building it, sets `true`. So there is no build gate waiting on this, and
#199's checkbox is being dropped rather than deferred (see #248).

This issue stands on its own merits — a broken root `build` script — and nothing is
blocked on it. Repriced accordingly: it is a contributor-experience papercut, not
infrastructure work.