feat(ui): show serving binary version (#1820)

[rarepops]

What does this PR do?

Fixes #1820.

• adds the compiled serving binary version to the existing /api/ui-config response
• shows a compact vX.Y.Z label beside the Codebase Memory name
• hides the label when the endpoint fails or returns no string version
• adds focused frontend coverage for visible, invalid, and unavailable states
• adds native endpoint coverage for the compiled version value

This uses the existing same-origin config endpoint and adds no external request, dependency, MCP method, or configuration key.

Validation

• cd graph-ui && npm test (46 passed)
• cd graph-ui && npm run build
• ./build/c/test-runner httpd under GCC ASan/UBSan (64 passed, 1 platform skip)
• make -f Makefile.cbm lint-format CLANG_FORMAT=clang-format-20
• git diff --check

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (make -f Makefile.cbm test) (full native suite not run; focused UI and HTTP suites passed)
• Lint passes (make -f Makefile.cbm lint-ci) (full lint not run; pinned formatting gate passed)
• New behavior is covered by a test

Screenshot

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Approved on merit. Small, well-scoped, and it follows the existing conventions rather than inventing any.

The CBM_VERSION fallback is exactly right. I checked before flagging it, and

#ifndef CBM_VERSION
#define CBM_VERSION "dev"
#endif

is verbatim the pattern already in src/main.c:103, src/mcp/index_supervisor.c:36 and src/cli/cli.c:99, with CI injecting -DCBM_VERSION (Makefile.cbm:74). So a build without the flag degrades the same way everywhere else does, instead of introducing a fourth convention.

Extending /api/ui-config rather than adding an endpoint is the right call too. It is same-origin, already fetched during load, and your description names what is not changing — no external request, no dependency, no MCP method, no config key. Stating the negative space is more useful than describing the positive change, because it is what a reviewer would otherwise have to go and check.

Handling the three display states separately — visible, invalid, unavailable — is what makes this safe on the frontend. Hiding the label when the endpoint fails or returns no string means a version that is missing never renders as vundefined, and each state has its own test.

On exposure: the version is already public via --version and the UI is loopback-only, so surfacing it on that endpoint discloses nothing new. Worth having considered, not worth blocking.

One note

Your validation shows make lint-format CLANG_FORMAT=clang-format-20. Our gate requires the Homebrew LLVM build, and the two disagree on some large files — usually reporting phantom drift, though I have just seen the reverse on another PR, where clang-format-20 passed locally and CI's pinned formatter found real violations in newly-added lines. So treat CI's lint / lint as authoritative here rather than your local pass. Nothing to do unless it goes red.

CI is still early (3 of 11 reported). I will merge on green — our Actions queue has been heavily backlogged today, though it is finally draining.