bug(server): /health reports component version "0.1.0" instead of the release version — downstream version gating impossible

[pescao0]

Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

Bug Description

GET /health returns "version": "0.1.0" on every build, including official brew releases. The field appears to be the HTTP server component's own version constant rather than the binary's release version, so downstream clients cannot use /health to gate on a minimum Engram version.

Steps to Reproduce

1. Install Engram via brew (release 1.16.1)
2. Run engram --version → engram 1.16.1
3. Run curl -s http://127.0.0.1:7437/health
4. Compare the two version strings

Expected Behavior

/health reports the release version (e.g. "version": "1.16.1"), matching engram --version, so HTTP clients can detect outdated servers and fail fast with an actionable message.

Actual Behavior

/health → {"service":"engram","status":"ok","version":"0.1.0"} while the binary is release 1.16.1. Verified on two machines (Linux dev + production box): the value is "0.1.0" regardless of installed release.

Operating System

Linux (also reproduced on a second Linux host)

Agent / Client

Other (custom HTTP client — Houdini panel integration)

Shell

bash

Relevant Logs

$ engram --version
engram 1.16.1
$ curl -s http://127.0.0.1:7437/health
{"service":"engram","status":"ok","version":"0.1.0"}

Additional Context

Impact we hit in production: our client shipped a minimum-version check based on the /health version field and it hard-stopped against every real server. We have since switched to a capability probe (probing the endpoint we need and treating 404/405 as "too old"), which works — but wiring the release version into /health (e.g. via build-time ldflags) would let HTTP clients do proper version gating. Happy to provide more details.