About FlyBot version line: no commit for a hoisted git install, and a pinned commit is shown as a branch #379

Follow-up to #374 / #375. Settings → About FlyBot shows the version line Version 0.1.5-flybot.1 · <branch> <commit> only when it can read the commit, and for the installs people actually have it often cannot:

1. The commit is read from the package's real path (installedCommit / commitIn in core/src/host/update.js), which only carries the commit under pnpm's isolated layout (.pnpm/...codeload.github.com+ThinkFlowLab+FlyBot+tar.gz+<sha>...). DSH profiles use nodeLinker: hoisted, so the real path is <profile>/node_modules/ds-bot and holds no commit: the line shows no commit and the update row cannot say how far behind it is. The profile's pnpm-lock.yaml has it: the ds-bot@https://codeload.github.com/ThinkFlowLab/FlyBot/tar.gz/<sha40>#path:/core entry (checked with a real pnpm add "github:ThinkFlowLab/FlyBot#main&path:/core" into a hoisted profile).
2. A 40-hex ref in the install spec is taken for a branch. github:ThinkFlowLab/FlyBot#<sha40>&path:/core makes sourceOf return branch: '<sha40>', so the page prints Version … · 6d04db6682fa87033e58a176121f878b3ba293ce, says it follows that "branch", and asks GitHub to compare against it.

Wanted

• Read the commit from the profile's pnpm-lock.yaml (the ds-bot entry's tarball .../tar.gz/<sha40>), falling back to the real-path match that exists today. A lockfile that cannot be read or has no ds-bot entry is not an error.
• A 40-hex ref in the spec is a commit: show its short SHA, never call it a branch, and compare against a branch only when a branch is known (#main).
• The update row for a commit-pinned install says it is pinned to that commit and updates come from reinstalling FlyBot.