feat(templates,schemas): render audience, derive the journal word count from Zola

[forkwright]

Two fixes that unblock a consumer, plus a design correction that removed a third. The PR pivoted mid-flight; this body describes what it is, not what it was.

1. The journal word count is derived, not declared

schemas/journal-entry.schema.json no longer requires extra.words / extra.words_source. journal-entry.html and journal-section.html render Zola's own page.word_count. An explicit extra.words still wins as an override, and words_source is required only alongside it (the dependentRequired pattern product.schema.json already uses for availability).

Why: the count was a hand-written claim that drifts. Measured against a consumer's 8 essays, three were materially wrong — ~1050 for 1263 words, ~1150 for 944, ~1120 for 1264. Written once, never updated as the essays were edited. A derived count cannot drift.

What page.word_count actually counts — verified against real builds with isolated per-variable fixtures, not assumed:

Included	Excluded
headings, emphasis/bold inner text	fenced code block content, entirely
inline code span content
link visible text and the link URL
image alt text and the image src path

Worth stating in the docs, because a reader of the rendered number deserves to know what it measures — particularly on essays containing code fences.

Demonstrated: second-entry (no extra.words) renders 93 words; appending a 23-word sentence renders 133 — hand-checked exact delta. first-entry keeps its ~120 words override.

2. audience is rendered, so requiring it is honest

extra.audience now renders in the entry header beside components, and stays required.

Its schema rationale claimed it was "required so rendered deliverables carry audience assumptions explicitly." Nothing rendered it — no template in this repo, no consumer template, no script. Outside the schema definitions it appeared only in test fixtures that existed to satisfy the requirement. A requirement justified by an effect that does not occur is the defect; the choice was to make the claim true rather than drop the field.

3. What was dropped, and why that is the interesting part

This branch first added an extra cascade, so a section could set audience once for all its pages.

Zola has no such mechanism. A bare [cascade] table is a hard unknown field error at 0.22.1 — verified directly, and confirmed absent through 0.23.3 release notes:

unknown field `cascade`, expected one of `title`, `description`, `sort_by`, `weight`,
`draft`, `template`, ... `page_template`, `aliases`, `generate_feeds`, `extra`

So the cascade was validator-only: it satisfied typikon-validate and told the renderer nothing. A page relying on it passed validation and then failed zola build against the render-time assert — reproduced before it was removed. That is a validate-passes/build-fails trap, and shipping one to fix a metadata gap would have been a bad trade.

Rendering audience moots it entirely: a rendered value must reach Zola, so it must live in the page's own frontmatter. ci/check-extra-cascade.py, the section.core.schema.json change, and the validator's cascade functions are all gone, and the two asserts removed while chasing it are restored — correct again, since they now guard a value that is genuinely rendered.

Verification

• bash ci/run-fixtures.sh (with ~/.npm-global/bin on PATH so pa11y-ci resolves) → exit 0, every stage pass.
• bin/typikon-check examples/sample-blog and examples/sample-shop → exit 0 each.
• Rendered output confirmed in built HTML: <p class="entry-audience">…</p> and <p class="specs">93 words</p> on the fixture with no override.