docs(fr-029): implementation plan for the metadata API + browser read-model

Ten tasks covering UI-1 (GET /_meta, five ports) and UI-2 (the browser
read-model), TDD throughout. Implements the 2026-09-20 design.

Writing it surfaced four things that would have failed at implementation time,
all verified against the tree rather than assumed:

- `canonicalSerializeEffective` is NOT in the metadata package's public barrel.
  index.ts:243 exports its three siblings and omits it; the only consumer today
  reaches it by deep relative import from inside the package's own tests.
- `TYPE_OBJECT`/`TYPE_FIELD`/`TYPE_VIEW`/`TYPE_LAYOUT` live in
  shared/base-types.ts, which constants.ts does NOT re-export. The browser
  read-model cannot compile without adding it — and it must be added there
  rather than imported from the root, which is what #287 forbids. The file is 62
  lines of pure `export const` with zero imports, so it is safe for that barrel.
- `MetaDataLoader.fromDirectory(dir)` is awaited DIRECTLY; it is not a builder
  with a `.load()`. Matched to the call shape already used in runtime-ts's tests.
- Effective output still emits `extends`, with inherited members inlined beside
  it, so the reader must IGNORE it. Resolving it would double-count every
  inherited member. That gets its own test.

The load-bearing test is Task 5: the same buildGrid runs over the real
MetaObject and over the browser model built from that model's effective
serialization, and the outputs must be deep-equal, across three fixtures that
inherit fields and views. Everything else could pass while the browser model
quietly disagreed with the real one.

Deliberately not in this plan: UI-3 (buildColumns + useMetaGrid, per the
2026-06-16 slice-1 design 5.4/5.5), UI-4 runtime forms, UI-7 demo, UI-8
verification. Each is its own plan once this lands.

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

Author: dmealing