media: runtime thumbnail service for attachments (currently serves originals as-is)

## What's deferred

Blog-post bodies (after PR #107 + follow-up) store **original** media bytes as gitsheets attachments under \`blog-posts//.\`. The API serves them via \`GET /api/attachments/:key\` — but as the original bytes, no resizing.

Practical consequences:

- A blog index card that wants a 200×200 thumbnail downloads the full 2MB JPEG and lets CSS scale it.
- A featured-image header that wants a 1920px wide hero downloads the same 2MB JPEG regardless of viewport.
- Per-render bytes-on-the-wire are 5-50× larger than they need to be.

We accepted this because:

- The legacy laddr server's \`/thumbnail//\` endpoint can't be relied on past cutover.
- Storing **originals** in the data repo is the right durable record.
- Resizing on demand is a runtime concern that can be added without changing the data shape.

## Fix shape

Add a thumbnail endpoint:

\`\`\`
GET /api/attachments/:key?w=200&h=200&fit=cover&format=auto
\`\`\`

- Reads the original blob from gitsheets.
- Pipes through \`sharp\` (already a dep — used in avatar uploads).
- Caches the resized output keyed by \`(blobHash, w, h, fit, format)\` so the same params return from cache after the first hit.
- Cache lives in the pod's memory or a tmpfs volume — invalidated on hot-reload (the blobHash key handles that naturally).

Alternative: precompute thumbnails at import time (write \`-200x200.jpg\` alongside \`.jpg\`). Trades repo size for runtime cost. Probably the wrong trade — variants explode quickly.

## Until then

Markdown bodies render \`\` tags pointing at \`/api/attachments/...\` and the browser pulls the full original. SPA can add \`loading="lazy"\` and CSS \`max-width\` for ergonomics; bandwidth cost is real but not blocking v1.

## Related

- Avatar upload (\`apps/api/src/routes/people.ts\`) already does a sharp-based resize at write time + stores both originals and 128×128 thumbnails. The pattern is established; the read-time variant would unify the two surfaces.

Start at the GET /api/attachments/:key endpoint and compare the sharp-based resize pattern in apps/api/src/routes/people.ts. Implement read-time variants using the original blob and the requested w, h, fit, and format parameters, with caching by blobHash and those parameters. Done means repeated requests reuse the cached resized output and originals remain stored unchanged.

Written by the indexing model from the issue text.