Repo page 'latest commit' banner shows stale/dangling commit regardless of selected ref

Summary

Found while publishing muse and musehub to production for the first time. The "latest commit" banner at the top of the repo file browser (musehub.ai/<owner>/<repo>?ref=<branch>) shows a commit titled "Initial commit" for every branch, regardless of which branch is actually selected — even though the file tree below it correctly reflects the selected branch's real content.

What "Initial commit" actually is

muse hub repo create auto-generates an empty placeholder commit on the default branch (main) at repo-creation time, titled "Initial commit". This is expected/fine on its own (comparable to GitHub's optional README-init commit). The bug is that after real content was pushed and main was force-pushed to point at real history (moving main's ref away from that placeholder — the placeholder is now a dangling, unreferenced commit reachable from no branch), the UI still displays that same dangling "Initial commit" as the "latest commit" banner on every branch's page, including dev, whose real head is a completely different, unrelated commit (a merge commit with a real message).

Confirmed via the wire API — this is a UI bug, not data loss

curl https://musehub.ai/gabriel/muse/refs
{"branch_heads": {"dev": "sha256:e8214e00...", "main": "sha256:278a5271..."}}

Neither branch head is the dangling "Initial commit" hash. The file tree rendered on ?ref=dev correctly shows the real project structure (docs/, muse/, scripts/, tests/, etc.) — only the banner above it is wrong.

Suspected root cause

The banner component likely queries/caches a fixed "first commit" or "latest commit as of repo creation" value rather than re-resolving the currently-selected ref's actual head on each page load. Possibly related to the same pushed_at-based staleness described in #171 — worth checking both together since they may share a cause.

Fix

The banner should resolve and display the real head commit for whichever ref is currently selected (matching what GET /<owner>/<repo>/refs already returns correctly), not a cached/default value.