Add typed renderer adapters for Jinja2, htpy, Jx, and tdom

[yhay81]

Outcome

Make hayate-htmx an engine-neutral, statically typed hypermedia layer with
first-party Jinja2, htpy, Jx, and experimental tdom rendering paths. This
implements the direction recorded in the maintainer-owned DESIGN.md without
making the Hayate core depend on a template engine.

Why now

• The competitive capability matrix still gives Django and Hono stronger
  framework-native HTML/component ergonomics in important profiles.
• htpy supplies typed Python components and async rendering.
• Jx supplies Jinja-backed components, typed props, slots, and component
  assets.
• tdom supplies Python 3.14 t-string components with default escaping.
• The existing page/fragment selection and Vary behavior are already
  renderer-independent; the remaining public type assumed string template
  names.

Phase 1 — public renderer boundary

• Introduce Renderer[ViewT] with one view type shared by page and
  fragment targets.
• Make HtmxTemplates[ViewT] generic without changing request selection,
  response, status, headers, or cache variation.
• Preserve the existing TemplateRenderer import as a compatible
  string-view protocol for the 0.x transition.
• Keep Jinja2 as the installed and documented default.
• Add strict typing tests proving that page and fragment targets cannot
  silently use incompatible view types.

Phase 2 — first-party adapters

• Add hayate-htmx[htpy] using htpy 26.x, including async component
  rendering and default escaping.
• Add hayate-htmx[jx] using Jx 0.11.x, including catalog reuse, props,
  slots, assets, default escaping, and normalized missing-component identity.
• Add hayate-htmx[tdom] using tdom 0.1.x only on Python 3.14+, with an
  actionable Python/extra error and no tdom import from the base package on
  Python 3.12/3.13.
• Add hayate-htmx[all] with environment markers that preserve the base
  package's Python 3.12 floor.
• Exercise the same page, fragment, history restore, htmx 4, escaping,
  async, missing-view, Vary, content-type, and response contract for every
  applicable adapter.

Phase 3 — runtime and scaffold evidence

• Prove every adapter currently claimed as Workers-compatible through real
  workerd/Pyodide: Jinja2 is covered by the golden app and htpy by a dedicated
  gate. Jx and tdom remain explicitly unclaimed.
• Add a renderer axis to create-hayate while keeping Jinja2 as the
  compatibility default and tdom experimental/Python-3.14-only.
• Keep generated routing, handlers, security, htmx behavior, and tests
  structurally equivalent across renderers.
• Publish package, compatibility, dependency, payload, and browser
  evidence before changing the competitive matrix.

Landed evidence

• hayate-htmx PR Add typed renderer adapters #10, squash commit
  92dfb05f387d2704597b53e73880144d5f594609
• hayate-htmx PR Test Jx slot and asset contracts #11, squash commit
  e26de517b301b7caf119609f62085bbf900ba7c3, proving named slot/fill and
  transitive CSS/JavaScript asset contracts
• hayate-htmx PR Prepare hayate-htmx 0.2.0 release #12, current reviewed 0.2.0 candidate commit
  c133900998c487a44d40a103c52f2d469047deda
• create-hayate PR #58, squash commit
  c8543a3487d2ff2e534e8f1e7a6b954e2704a6ce
• create-hayate final PR CI:
  https://github.com/hayatepy/create-hayate/actions/runs/30316313742
• create-hayate final renderer/browser/workerd smoke:
  https://github.com/hayatepy/create-hayate/actions/runs/30316313791
• create-hayate full default matrix: 112/112 declared compositions:
  https://github.com/hayatepy/create-hayate/actions/runs/30316596549
• Python 3.12, 3.13, and 3.14 tests
• strict mypy positive and negative type contracts
• built-wheel base/htpy/Jx/tdom isolated-install checks
• dependency audit, CodeQL, and workflow static analysis
• Chromium htmx 2 and observational htmx 4 browser checks
• real workerd/Pyodide htpy full-page and fragment rendering with escaping,
  content type, and Vary assertions
• renderer source is immutable and auditable while the public package is
  unavailable: ASGI uses the reviewed Git commit and Workers bundles
  hash-checked source files from the same commit

Remaining publication gate

The implementation and generated-scaffold evidence are complete. The package
is not yet on PyPI because its one-time pending trusted publisher has not been
configured. Until that external setting is complete, create-hayate remains
unreleased with the renderer axis and the competitive matrix must not claim
public-package availability.

Sources reviewed

• https://htpy.dev/how-to/async/
• https://jx.scaletti.dev/docs/quickstart/
• https://pypi.org/project/tdom/0.1.18/

Non-goals

• Moving rendering into hayate core.
• Claiming tdom stability while it remains pre-alpha.
• Claiming Workers compatibility from CPython-only tests.

[yhay81]

The downstream create-hayate renderer axis is now implemented and fixed in local commit d16af86 (not pushed yet): Jinja/htpy/Jx/tdom on ASGI, Jinja/htpy on Workers, and fail-closed rejection for unproven Workers pairs.

Evidence includes byte-for-byte Jinja compatibility, generated pytest/Ruff contracts, Chromium journeys for every claimed adapter, and the full htpy Workers contract through real workerd. The create-hayate repository gate is also green (86 tests, Ruff, mypy, doc drift, Zizmor, pip-audit).

Phase 3 remains intentionally unchecked until the package release order is complete: publish hayate-htmx 0.1, release create-hayate 0.7.1 on that public dependency, publish the renderer adapters as hayate-htmx 0.2, then push/rebase/merge the renderer scaffold and release create-hayate 0.8.0. This avoids committing a knowingly unresolved PyPI dependency to main.

[yhay81]

Release preparation is now merged through #12 at c133900998c487a44d40a103c52f2d469047deda.

The 0.2.0 candidate passed all blocking GitHub gates: Python 3.12/3.13/3.14, isolated base/htpy/Jx/tdom wheel installs, real workerd htpy, Chromium htmx 2 and observational htmx 4, Hayate 0.12/latest compatibility, dependency audit, and workflow audit.

Remaining Phase 3 order:

1. complete the pending PyPI trusted publisher and publish immutable 0.1.0;
2. tag/publish 0.2.0 from the reviewed main commit;
3. merge the already prepared create-hayate 0.7.1 and renderer-axis 0.8.0 branches;
4. refresh released-artifact compatibility evidence and then update the competitive matrix.

[yhay81]

Phase 3 implementation and scaffold evidence are complete.

• create-hayate #58 merged as
  c8543a3487d2ff2e534e8f1e7a6b954e2704a6ce.
• Final renderer smoke passed Jinja, htpy ASGI, htpy real Workerd, Jx ASGI,
  tdom Python 3.14 ASGI, React, and Astro:
  https://github.com/hayatepy/create-hayate/actions/runs/30316313791
• Merge-commit CI passed:
  https://github.com/hayatepy/create-hayate/actions/runs/30316497399
• Current-main full default matrix passed 112/112:
  https://github.com/hayatepy/create-hayate/actions/runs/30316596549
• Aggregate evidence SHA-256:
  69b6b9cfc83288e8ec4d0fade8ff24857394e17e1c3a04c228c1b39485fa8e15.

The issue remains open only for public-package/distribution evidence. Until
the PyPI trusted publisher in #7 is configured, create-hayate will not release
the renderer axis and the competitive matrix will not claim public
hayate-htmx availability.