Every undeclared site.options key is dropped by the CLI, so twitter and launch_* never reach the theme

[mmcky]

Found while building Phases 4–5 (#90, #91). The MyST CLI validates site.options against the template's declared options and drops every key the template does not declare (validateTemplateOptions in myst-templates: the output object is built only from the declared definitions; unknown keys log at debug level). Until #90's branch, this theme's template.yml declared no options at all, so config.options arrived as {} on every site. Verified on the visual fixture, whose site.options.logo_text never appears in _build/site/config.json.

That means several options the theme reads have never worked from myst.yml:

Read in	Key	Effect today
app/root.tsx, both page routes	twitter	Twitter card meta never gets the handle
app/components/toolbar/LaunchButton.tsx	launch_repo_url, launch_repo_suffix, launch_branch, launch_notebooks_path, launch_source_path	the launcher always uses the defaults; the generalisation in launchUrls.ts is unreachable from config
app/backend/loaders.server.ts	favicon	always the mystmd default
app/components/Document.tsx (upstream shape)	analytics_google, analytics_plausible	no analytics can be configured
app/components/Page.tsx	hide_toc, hide_search, hide_outline, hide_title_block, outline_maxdepth, hide_footer_links	ignored
fixture	logo_text	ignored

Page-level site: frontmatter is a different path. The CLI validates it with the same definitions but, when the validated result is empty, leaves the page's raw site: block in place. That is the only reason site.git_metadata works on the fixture's features page and in the git-metadata plugin's override. Two consequences worth knowing:

1. A page that sets any declared key under site: has its whole block replaced by the validated keys, so an undeclared git_metadata on that page is silently lost. Phase 4 — Internationalisation (language switcher + hreflang) #90's branch documents this in app/types.ts and keeps the two on different fixture pages.
2. A declared option's default: is written into every page's validated block even when the page set nothing, which then overrides the site-wide value. Phase 4 — Internationalisation (language switcher + hreflang) #90's branch therefore declares no defaults in template.yml and applies them in code.

Proposed fix. Declare in template.yml every option the theme reads, one options: entry each (twitter, the five launch_*, favicon as type file, the two analytics_*, the hide_* / outline_maxdepth set), with no default: values, and add a fixture assertion that a declared option reaches config.options. Then decide what to do about git_metadata: it is an object, which a template option cannot declare, so the page-level override survives only by the empty-validation quirk above. Moving the page-level override to mdast.data (where the plugin already writes) would take it off that path.

Options that cannot be declared. Template option types are boolean, string, number, choice and file only. Any structured option has to be a string (#90 uses a YAML block string for languages and translators) or live somewhere the CLI preserves. A real list / object option type in the engine would remove the workaround; that is a QuantEcon/mystmd (and upstream) change, not a theme one, and is noted on the upstream-candidates ledger.

[mmcky]

Fix open as #194. Two things settled there that this issue left open.

git_metadata: declared as a string holding a YAML block, the same form languages and translators take, and parsed by PageHeaderHistory with the existing parseStructured; an object still passes through. Moving the override into mdast.data instead would have needed the plugin to read page frontmatter, which is a change in the plugin's new home (QuantEcon/quantecon-plugins.mystmd#11) rather than here, and declaring it keeps the override a theme contract. The fixture's features page now sets git_metadata beside a declared key, the case that used to lose it silently.

favicon had a second blocker beyond being undeclared: a static public/favicon.ico was served ahead of the [favicon.ico] route on every request, so the option never took effect even once declared. It is the QuantEcon lectures favicon, byte-identical to the Sphinx sites', so it becomes the route's default from public/logos/ and a configured favicon is fetched from the content server as the CLI copied it.

The four typed-but-unread keys (hide_outline, hide_title_block, hide_footer_links, outline_maxdepth) are dropped from the types rather than declared. Every other row in the table above is declared and covered by a site-options fixture assertion.