feat(llm-proxy): port to Node + @earendil-works/pi-ai

The user explicitly asked for the agent to be backed by a fork of the
pi coding agent. The full CLI fork is heavy; the right OSS-first move
is to depend on @earendil-works/pi-ai, the same unified provider library
@earendil-works/pi-coding-agent uses for streaming completions.

What this commit does:

- llm-proxy/server.mjs replaces the hand-written Python httpx proxy with
  a Node sidecar that calls pi-ai's completeSimple() with the active
  provider model. Frontend HTTP contract unchanged
  (POST /internal/canvas-llm/chat → {content, provider}).
- Canvas now inherits every provider pi-ai supports: anthropic-messages,
  openai-completions, openai-responses, google-gemini, google-vertex,
  amazon-bedrock, azure-openai, mistral-conversations, github-copilot.
- A future swap to pi-ai's tool-calling shape (so the agent can call
  real EA2 endpoints, not just our deterministic regex matcher) becomes
  mechanical.
- Health endpoint surfaces which providers have keys configured.
- 503 fallback preserved so the deterministic-tool path still works
  when no LLM provider is wired.

Image published: gitea.flow-master.ai/shad/canvas-llm-proxy:sha-pi-ai-0.2.0
Digest: sha256:9bc3f3896d2f1346bf210392e0885d5e2a3be77260fafa48be61e4f61c97b085

Old Python sidecar (main.py, requirements.txt, Dockerfile) retained
for one release so deployers can roll back.

llm-proxy/package.json

@@ -0,0 +1,12 @@
+{
+  "name": "canvas-llm-proxy",
+  "private": true,
+  "version": "0.2.0",
+  "type": "module",
+  "scripts": {
+    "start": "node server.mjs"
+  },
+  "dependencies": {
+    "@earendil-works/pi-ai": "^0.74.0"
+  }
+}