feat(registry): add a reusable docs landing block

[GSTJ]

What changed

pnpm dlx shadcn@latest add GSTJ/magic/docs-landing writes four editable files
into a consumer repo. They cover a dark landing shell, hero, stat strip,
sections with three layouts and five tones, a demo frame, a release timeline, a
final CTA, a footer, and an accessible clipboard button for the install command.
It installs gsap@3.15.0 and nothing else. Demos, examples, palette overrides
and copy stay in the repo that installs it.

Also here:

• registry.json at the repo root, plus the flat public/r payloads for the
  HTTPS address the shadcn Registry Directory will want later
• scripts/validate-registry.mjs, which checks catalog metadata, item names and
  types, the file list, embedded source, missing and extra output, and stale
  generated payloads, with 185 lines of tests behind it
• registry/tsconfig.json, because nothing under registry/ is a package and
  turbo run typecheck was never compiling these files

Screenshots

Installed from this branch into a clean Next 16.2.12 app with strict TypeScript
and noUncheckedIndexedAccess, then composed into a page that exercises every
export.

Same page under prefers-reduced-motion: reduce, captured without scrolling.
All 19 reveal targets are at full opacity because the reveal timelines never
register under that media query:

Review notes

All fixed in b308786.

The branch was three commits behind main, including the
magic-oxlint-config@2.0.0 breaking release, so the green CI on the old head
was green against the wrong base. Rebased; pnpm run check is 95/95 on the new
one.

Nothing typechecked the block. registry/ is not a package, so no build
compiles it and turbo run typecheck skipped it: four files, ~1700 lines, that
a consumer compiles and this repo did not. registry/tsconfig.json extends
magic-tsconfig/nextjs and pnpm run typecheck runs it. Broke a type on
purpose to confirm it fails on one.

validate-registry only ran in one of the two CI jobs. It was in the root
check script but not in self-ci.yml's extra-command, so the
reusable-workflow job skipped it. Both lists match now.

The CLI resolves GSTJ/magic/docs-landing by reading registry.json and the
source files from raw.githubusercontent, so the install works with nothing
hosting the repo. public/r is not on that path. It is there for the Registry
Directory entry, which needs a stable HTTPS URL this repo does not have yet. The
README says so.

The presets are untouched, so the extendConfig rule is unaffected. gsap,
react, react-dom and @types/react are new root devDependencies, only so
the typecheck can resolve what the block imports.

Validation

• pnpm run check on the rebased branch: pass, 95/95 adversarial expectations
• pnpm run typecheck:registry: pass, and fails on a deliberately broken type
• pnpm run validate-registry: pass
• real install from this branch into Next 16.2.12: four files, imports rewritten
  to @/components/docs-landing/*, gsap@3.15.0 added
• tsc --noEmit and next build in the installed fixture: pass
• rendered in a browser at 1440px, scrolled top to bottom, zero console errors
  and zero elements left hidden
• reduced motion: 19 of 19 reveal targets visible with no scroll

[GSTJ]

The pushed branch resolves as a real GitHub registry now. Review it with: pnpm dlx shadcn@latest view GSTJ/magic/docs-landing#agent/docs-landing-registry. Remote registry validation passes for GSTJ/magic#agent/docs-landing-registry. The unpinned install command in the README becomes active after this PR lands on main.

[GSTJ]

Follow-up acd6cf5 adds the checked-in flat shadcn payload and drift tests.

Review without writing files:

pnpm dlx shadcn@latest add GSTJ/magic/docs-landing#agent/docs-landing-registry --dry-run

Fresh integration verification: full pnpm check, local registry validation/build, remote branch validation, and remote item resolution all pass. The future @magic upstream entry remains gated on this PR being reviewed and merged so its stable main/public/r/*.json endpoints exist.