feat(templates): make the favicon path configurable like every sibling brand asset

[forkwright]

Closes #110

Finding

templates/base.html:16 hardcoded <link rel="icon" href="/img/favicon.svg" type="image/svg+xml">. Of the sibling brand-identity values in config.toml [extra], og_image (templates/base.html:43-47) is the only one that resolves through get_url() at all — though unlike the favicon_path fix, an unset og_image omits its <meta> tag entirely rather than falling back to a default(), so "identical shape" overstates it too; logo_path is a separate raw-concatenation shape used in templates/partials/nav.html:8 and templates/partials/ld-organization.html:14 (not base.html's head block, and not through get_url() at all); theme_color is a color string, not a path. The favicon alone had no config knob at all, so a consumer whose brand mark lives anywhere else had to place a second copy at typikon's exact path (forkwright/ardent-site#12 is the filed consequence: three byte-identical SVGs, one of them existing only to satisfy this path).

Evidence

• templates/base.html:16-31 now reads favicon_path from config.extra through get_url() with a default() of img/favicon.svg (unaffected existing consumers), and derives the <link>'s type= from favicon_path's own extension (svg/ico/png/gif/jpg/jpeg/webp) instead of leaving it hardcoded — see "Findings from adversarial review" below for why this half of the fix exists.
• bin/typikon-init:192 scaffolds # favicon_path = "img/favicon.svg" into every new consumer's config.toml [extra], next to the existing # logo_path line.
• docs/AGENTIC.md:190 documents favicon_path in the brand-identity table, including the type-derivation behavior.
• ci/check-favicon-path.py builds a real fixture site with zola build three times: favicon_path unset (theme default resolves, unaffected), set to a custom SVG (the original defect — before the fix, favicon_path had no effect on the rendered href at all), and set to a custom .ico (the type= must follow the extension, not stay hardcoded). Locally: OK: favicon <link> resolves the theme default when unset, a consumer's favicon_path when set, and a type= matching that asset's own extension.
• ci/check-init-favicon-path.py runs the real bin/typikon-init against two genuinely isolated environments and asserts the scaffolded config.toml carries favicon_path defaulted to img/favicon.svg in both. Locally: OK: bin/typikon-init scaffolds config.toml [extra] with a favicon_path key defaulted to img/favicon.svg in both a genuinely identity-less environment (fallback engages, commit uses the fixed typikon-init identity) and one with a real git identity configured (fallback stays out of the way, commit uses the caller's own identity).
• ci/run-fixtures.sh wires both checks into the fixture gate.

A second, independent defect, fixed in the same PR because it blocks this PR's own CI: ci/check-init-favicon-path.py is the first CI check to invoke bin/typikon-init end-to-end. It exposed that the scaffold commit (previously an unconditional git commit -q -m "chore(${SITE_NAME}): scaffold from typikon") depends on an ambient user.name/user.email that a fresh CI runner or agentic sandbox does not have. bin/typikon-init:305-316 now checks whether user.email/user.name resolve at all, and only when neither does, scopes a fixed identity (typikon-init <typikon-init@localhost>) to that one commit via git -c.

Findings from adversarial review, and how each was closed

An independent adversarial reviewer returned must_fix against an earlier state of this PR. Every finding below is addressed in the diff or this body, not asserted away:

1. The PR body a CI run validated was not the PR body currently on the PR. A prior edit to this body landed mid-flight during the gate / ai-attribution and gate / check-trailer runs (both scan the PR_BODY env var as it exists when the job starts). This PR now carries a new commit (the .ico MIME-type fix) that triggers a fresh CI run against the body as it reads right now — the reviewer or anyone else can confirm the head SHA on the most recent gate-attestation run matches this body's edit time.
2. Two limitations the earlier draft flagged were silently dropped from a later edit rather than fixed or tracked. Both are now handled:
   • The <link>'s type= staying hardcoded to image/svg+xml regardless of favicon_path — fixed, not just noted: templates/base.html now derives type= from the configured path's extension, and ci/check-favicon-path.py's third case is the regression fixture. Verified as a genuine negative case: reverting the derivation to the old hardcoded type="image/svg+xml" makes that fixture fail (FAIL: ico-favicon fixture: expected type image/x-icon ... got 'image/svg+xml') while the other two cases stay green (they never exercise a non-SVG extension); restoring the fix turns it green again.
   • get_url() performing no existence check, so a mistyped favicon_path builds and ships a broken favicon silently — real, confirmed by direct reproduction (zola build and zola check both exit 0 against a favicon_path pointing at a file that does not exist; the rendered <link> references it anyway), not fixed here, filed as get_url() performs no existence check for consumer-declared asset paths (favicon_path, logo_path, og_image) #155. It is not new: logo_path and og_image share the identical gap and predate this PR (also verified directly — a nonexistent logo_path builds clean too). Scoping the fix to favicon_path alone would import a known defect into a brand-new config key; the shared, pre-existing nature of the gap across three keys makes a general existence-check pass (issue get_url() performs no existence check for consumer-declared asset paths (favicon_path, logo_path, og_image) #155) the right unit of work, not something to hand-roll narrowly inside this PR.
3. The "33 kanon-lint warnings, before and after, identical" claim was unverified and, on reproduction, wrong. .github/workflows/gate-attestation.yml:44-53 confirms kanon lint is forge-only and not run by this repo's GitHub Actions gate, so this claim has never been CI-verified — it is asserted here as a locally-verified figure only. Running the exact command .kanon-ci.toml's lint stage specifies, kanon lint . --summary, against this branch's head produces 1 violation (PY/bare-except at ci/asset-provenance-scan.py:311), not 33 — and that one violation is pre-existing and unrelated to this diff: the same line, unchanged, is present on origin/main (confirmed via git show origin/main:ci/asset-provenance-scan.py). This PR's own new/changed files (templates/base.html, bin/typikon-init, ci/check-favicon-path.py, ci/check-init-favicon-path.py, docs/AGENTIC.md) introduce zero new lint violations.
4. The git-identity fixture only incidentally exercised its own fallback branch. The original ci/check-init-favicon-path.py spread the caller's ambient os.environ into the bin/typikon-init subprocess rather than neutralizing it, so it passed on GitHub Actions runners (which happen to start with no git identity) without ever proving the fallback works on a box that HAS one configured — or, more importantly, without proving the fallback stays OUT of the way when a real identity exists. Rewritten to build two genuinely isolated HOME environments (GIT_CONFIG_NOSYSTEM=1, no inherited GIT_AUTHOR_*/GIT_COMMITTER_*): one with no identity anywhere the isolated env can see (forces the fallback branch), one with a real identity seeded into the isolated HOME's .gitconfig (forces the fallback to correctly NOT engage). Both assert not just exit code but the actual commit author, so a fallback that fired when it shouldn't have would also be caught. Verified as a genuine negative case: reverting bin/typikon-init's fallback to the old unconditional commit and re-running the new fixture reproduces the original failure exactly (fatal: unable to auto-detect email address ... exit 128) on the no-identity case; restoring the fix turns it green again.
5. The "every sibling brand asset reads through get_url()" claim overstated its precedent. Corrected in the Finding section above: og_image is the only sibling that uses get_url() at all, and even it differs from the favicon_path fix (omits its tag when unset rather than falling back to a default()); theme_color isn't a path and logo_path is two raw-concatenation call sites, neither via get_url(). This doesn't change what the code does, only what the body claims it's consistent with.

Why this matters

The duplication is not a consumer mistake; it is the shape this template forces. Any consumer whose brand mark is not literally at /img/favicon.svg inherited the same duplicate SVG, and the defect was per-consumer and permanent rather than one-off.

Separately: a scaffolding tool whose only job is to bootstrap a fresh site, and that hard-fails the moment it runs somewhere with no pre-existing git identity, defeats the repo's own stated design ("optimized for agentic operation... humans should not need to develop here" — README.md:11). An agent or CI container is exactly the environment most likely to have no git identity configured.

Desired correction

• favicon_path added to config.toml [extra], defaulted to img/favicon.svg, rendered through get_url() — done (templates/base.html:16-31).
• <link> type= follows the configured asset's own extension — done (templates/base.html:16-31; not part of favicon path is hardcoded while every sibling brand asset is configurable, forcing consumers to duplicate their logo #110's original scope, added because making the path configurable without it is half a contract).
• Documented in the brand-identity table in docs/AGENTIC.md — done (docs/AGENTIC.md:190).
• bin/typikon-init's scaffold no longer requires an ambient git identity to complete — done (bin/typikon-init:305-316), and the regression fixture now genuinely forces both branches (ci/check-init-favicon-path.py).
• get_url()'s missing existence check across favicon_path/logo_path/og_image — tracked, not fixed here: get_url() performs no existence check for consumer-declared asset paths (favicon_path, logo_path, og_image) #155.

Done when: a consumer can point the favicon at an existing asset without placing a duplicate, and ardent-site can delete two of its three identical SVGs.