feat(docs-site): thread consumer providers into the meta docs --site surface

[dmealing]

Problem

meta docs --model/--api (markdown surfaces) load metadata via the sdk
loadMemory({ providers }), so they already honor a project's
metaobjects.config.ts providers — custom field/view/object subtypes. The HTML
--site surface has its own loader (docs-site's loadModel) with a
hard-coded registry, so a model using a consumer subtype (e.g. a custom view.*
on a field) failed on --site alone with Unknown type "…" — not registered,
even though the config declared its provider and every other surface resolved it.

Found by dogfooding a real ~660-page downstream model whose admin-UI metadata
carries custom view.* subtypes: markdown docs rendered, --site threw.

Fix

• docs-site: loadModel(sourceDirs, extraProviders = []) composes consumer
  providers AFTER the built-in bundle (core-types/db/doc/prompt/ui), mirroring
  loadMemory's providers; SiteOptions gains extraProviders; re-export
  MetaDataTypeProvider. Additive — default none, so config-less callers are
  unchanged (acme golden byte-identical).
• cli: emitSite threads the configProviders the docs command already
  loads from metaobjects.config.ts into generateSite (both the site-only and
  the additive-with-markdown paths), so meta docs --site resolves custom
  subtypes the same way the markdown surfaces do.

Tests

• docs-site/test/provider-extension.test.ts — a custom field subtype fails to
  load without its provider, then resolves via extraProviders and renders a site.
• cli/test/docs-command.test.ts — reuses the existing custom-type project
  fixture to prove meta docs --site now honors config providers (end-to-end
  through the real command).
• Regression: acme golden byte-identical; docs-site + cli typecheck clean; full
  build green.

🤖 Generated with Claude Code