Web client feature parity: Word export, custom templates (working branch), TikZ (design)

[flokchvtr]

Motivation

The self-hosted web client stubs out several desktop features that don't actually require Electron. Running ZenNotes through the Go server, the gap that hurts most day-to-day:

1. Word export — rejects with "available in the desktop app", but the serializer is pure unified/remark/docx and the vault's images are already served over /assets/raw. It can run entirely in the browser.
2. Custom templates — supportsCustomTemplates: false because the server has no way to list .zennotes/templates/. Read/write are already reachable; only a listing route (plus a capability flag, following the supportsAssetOps pattern) is missing.
3. TikZ — needs a real render process (node-tikzjax's wasm TeX engine), but the server could proxy to an operator-configured one, the same way search capabilities already adapt to what the host provides.

Proposal

I have (1) and (2) working, capability-gated so older servers and the desktop build are untouched, with Go tests for the new routes: branch flokchvtr/zennotes:web-feature-parity, ready to open as a PR if the approach looks right.

For (3) I have a working design (a ~35-line Node HTTP sidecar reusing apps/desktop/src/main/tikz.ts compiled standalone, ZENNOTES_TIKZ_UPSTREAM on the server, supportsTikz capability) but it raises deployment questions (should the Docker image ship the render process?) that deserve their own discussion.

Happy to adjust scope or split differently.

[flokchvtr]

Closing this — I'll propose the changes directly as focused PRs instead (first one: #594).