Record the theme version on generated PDFs

[sehkone]

Context

A generated PDF carries no record of which theme version produced it.

Both places the installed version is recorded are deliberately kept out of the build: docs/theme/.meta is dot-prefixed, so MkDocs excludes it, and docs/theme.toml is listed in the base config's exclude_docs. Verified by building the manual sample — neither site/theme/.meta nor site/theme.toml exists, and no version string appears anywhere in the output. That exclusion is correct; theme machinery should not be published.

The consequence only matters for the PDF. A site is regenerated continuously from a repository anyone can inspect, so the version is a git log away. A PDF is a file handed to a customer, detached from the repository that built it. When someone reports that a cover renders wrong or a table breaks across pages badly, there is nothing in the artifact that says which theme version to reproduce against — and once four repositories are bumping the theme on independent schedules, "which version was this built with" stops being answerable by inference.

Scope

Render the theme version on the PDF.

• Read version, template, and source from docs/theme/.meta in build-docs-pdf.sh, which does not read that file today.
• Render the version in the existing cover footer, alongside the date and copyright lines that pdf/cover.html.j2 already lays out. It should read as build provenance, not as a title — small, and clearly subordinate to the document's own version if the consuming project has one.
• A source = "local" install has a version copied from docs/theme.toml that never came from a release, so it must not render as though it did. Render it in a form that cannot be mistaken for a released version, or omit it and render an explicit local-build marker.
• Fail the build if .meta is missing or unreadable while docs/theme/ exists, rather than silently rendering a PDF with no provenance. A missing docs/theme/ already exits with its own message.

Acceptance criteria

• A PDF built from a release install shows the theme version on the cover.
• A PDF built from a --source install shows a marker that cannot be read as a released version.
• The rendered value matches version in docs/theme/.meta, not the requested value in docs/theme.toml, so a drifted or hand-edited install does not misreport itself.
• Removing docs/theme/.meta while keeping docs/theme/ fails the build with an actionable message.
• Both en and ko covers render it, with the label localized the same way the existing cover strings are.
• tests/pdf-test.sh covers the release form, the local form, and the missing-.meta failure.
• shellcheck passes.

Constraints

• Do not publish .meta or theme.toml to the site. The exclusion is intentional and this issue does not revisit it.
• Do not add a second file recording the version. .meta is the single record of what is installed.
• Do not change the extra.pdf contract. The version is build provenance the script derives, not something a consumer configures.
• Do not modify any consuming repository.

Out of scope

Showing the theme version on the HTML site. The need is weaker — a site is rebuilt from an inspectable repository — and the mechanism is a design decision rather than an implementation detail: Material's footer needs a template override, publishing a marker file would duplicate .meta, and re-including .meta through an exclude_docs negation depends on a subtle interaction with MkDocs' dotfile handling. Decide that separately if the need appears.