Add ty-llmtrim extension + plugin-architecture discussion

[bborn]

What

Adds extensions/ty-llmtrim — the TaskYou analog of the llmtrim-herdr plugin — and a design doc that answers the second half of the ask: discuss herdr's plugin architecture and make sure TaskYou supports the same kind of extensibility.

ty-llmtrim (the extension)

llmtrim is a local proxy that compresses LLM requests (upstream measures −31% input / −74% output tokens, no quality change). This extension wires it into TaskYou executors and surfaces savings. It's a self-contained Go sidecar, consistent with the existing extensions/ pattern (ty-qmd, ty-email, ty-web, ty-chrome):

Command	Role (maps to llmtrim-herdr)
ty-llmtrim up	configure routing + start daemon — bootstrap.sh / workspace.created
ty-llmtrim check	verify routing active — check-routing.sh / pane.agent_detected
ty-llmtrim watch / badge	savings poller (-31%/--/off) — savings-annotate.sh
ty-llmtrim down	stop daemon — stop-annotate.sh / workspace.closed
ty-llmtrim env	print HTTPS_PROXY/CA lines that route executors through the proxy
ty-llmtrim status / doctor	savings report / diagnostics

llmtrim is a transparent HTTPS proxy (routes via HTTPS_PROXY + a local CA), so agents launched by the daemon inherit routing from the shell profile llmtrim setup writes; ty-llmtrim env exposes the same values for explicit per-task injection.

docs/extensions.md (the discussion)

• How TaskYou is extended today (sidecars over MCP / executor-env / event feed / notify) — real, but convention, not contract.
• herdr's model: declarative manifest + host-dispatched lifecycle hooks + declarative UI (badges/actions).
• Gap analysis, and a proposal for a thin plugin loader: manifest discovery, hook dispatch, and — the one genuinely-missing seam — executor-env injection (so a proxy/transform extension routes agent traffic deterministically). Ships the proposed manifest format as ty-extension.toml.

Decision for review

This PR deliberately does not touch the executor launch path. The recommendation in the doc is to land the loader (esp. executor-env injection) as a separate, reviewed change — it's near the claudeEnvPrefix / BuildCommand divergence that caused past "lost executor pane" regressions, so it deserves its own PR. Want me to follow up with that host-side change, or keep extensions on the existing inherited-env seam?

Test plan

• cd extensions/ty-llmtrim && go test ./... — passing (status parsing, badge semantics, env rendering, graceful "off" when daemon down).
• go vet ./... clean, gofmt clean.
• Smoke-tested status / badge / check with no llmtrim installed → degrades to off / non-zero exit as designed.
• Self-contained module (own go.mod); root CI (go test ./..., golangci-lint, govulncheck) is unaffected — same as the other extensions.

🤖 Generated with Claude Code