docs: lowercase internal docs + migrate website docs to public-docs/ (#634)

* docs: rename to lowercase + drop leftover plans

Rename docs in docs/ to lowercase kebab-case for consistency and update
all references in CLAUDE.md, CONTRIBUTING.md, CHANGELOG.md,
packages/server/CLAUDE.md, and inter-doc links.

Drop two leftover design plan docs:
- docs/ATTACHMENT_BASED_REVIEW_CONTEXT_PLAN.md
- docs/plan-approval-normalization.md

* docs: drop stale uppercase entries from case-insensitive rename

* feat(website): power /docs from public-docs/ markdown tree

Move website docs out of TSX route components and into a root-level
public-docs/ directory of plain markdown files with frontmatter
(title, description, nav, order).

- Add packages/website/src/docs.ts loader using import.meta.glob with
  ?raw to compile the markdown into the bundle at build time.
- Replace the 9 hand-written docs/*.tsx routes with a single $.tsx
  catch-all that renders any slug via react-markdown.
- Drive the docs sidebar nav from frontmatter order/nav.
- Auto-discover docs routes in vite.config.ts so the sitemap stays in
  sync without manual edits.

* fix(website): bind dev server to 0.0.0.0 so port collisions trigger fallback

`host: "127.0.0.1"` (or unset) lets macOS coexist with another process
holding an IPv6 dual-stack `*:8082` socket, so Vite never sees
EADDRINUSE and silently binds alongside it. Forcing IPv4 wildcard
makes the conflict real, and Vite's default `strictPort: false`
falls through to the next free port.

* fix(website): restore docs page styling after markdown migration

Add a .docs-prose class that mirrors the styling the original
docs/*.tsx components hand-rolled (h1/h2/h3 sizes, paragraph/list
spacing, link colors, code blocks, callout-style blockquotes).

ReactMarkdown was emitting unstyled HTML because the previous
wrapper class only had inline-code rules — headings and code
blocks fell back to user-agent defaults.

docs/design.md

@@ -0,0 +1,73 @@
+# Designing Features
+
+How to think through a feature before writing code.
+
+## Start from the user
+
+Even for backend work, start from the user's perspective:
+
+- What problem does this solve?
+- What triggers it? User action, schedule, event?
+- What does success look like from the user's perspective?
+- What data does it need? Where does that data come from?
+
+## Map existing code
+
+Before designing anything new, understand what exists:
+
+- Where does similar functionality live?
+- What patterns does the codebase already use?
+- What layers exist? (See [architecture.md](./architecture.md))
+- What types and data shapes are already defined?
+
+New features rarely mean only new code. Usually they require modifying existing interfaces, extending existing types, or refactoring to accommodate the new functionality. Identify what needs to change, not just what needs to be added.
+
+## Define verification before implementation
+
+Before designing the solution, define how you'll know it works:
+
+- What tests will prove this feature is correct?
+- At what layer? Unit, integration, E2E?
+- What's the simplest way to verify the core behavior?
+
+If you can't define verification, you don't understand the feature well enough yet.
+
+## Design the shape
+
+### Data
+
+- What types are needed?
+- Use discriminated unions — make impossible states impossible
+- One canonical type per concept (see [coding-standards.md](./coding-standards.md))
+
+### Layers
+
+- What belongs in each layer?
+- Where are the boundaries?
+- What does each layer expose to the layer above?
+
+### Interactions
+
+- How does data flow through the system?
+- What triggers what?
+- Where do side effects happen?
+
+### Refactoring
+
+- What existing code needs to change?
+- Is existing code testable enough? If not, that's part of the plan.
+
+## Create a concrete plan
+
+Once the design is clear:
+
+1. **Acceptance criteria** — specific, verifiable outcomes (not "should work well" but "returns X when given Y")
+2. **Ordered steps** — what to build first (usually: types, then lowest layer, then up)
+3. **What to refactor** before adding new code
+4. **How to verify** each step
+
+## Principles
+
+- **Fit, don't force** — new code should fit existing patterns, or refactor first
+- **Simple** — the best design is the simplest one that works
+- **Verify early** — define how to test before designing the implementation