feat(menu): show the commit SHA in the version footer

[bmc08gt]

The version footer's build number is git rev-list --count HEAD, which only identifies a commit if you also know which branch was built. This adds the first 10 characters of the commit SHA, and splits the footer over two lines:

Version 2026.9.3 • Build 4623
2acfecffeb • beta

The iOS app is getting the same change in a parallel PR, with the same format: the break after the build number, no bullet at the start of the second line, and * for a dirty build.

• Two lines. On a 1080px-wide screen at the default font size, the one-line version with the development track ran almost edge to edge. A larger font or a narrower phone wrapped it at an arbitrary point, sometimes inside Build 4623 or the hash. A production build has no track, so its second line is just the hash.
• Length. The SHA is always cut to 10 characters, not git's variable default abbreviation, so both platforms render the same string. The formatting lives in VersionInfo.commitLabel.
• Dirty builds. A build with uncommitted changes to tracked files shows 2acfecffeb*. The check is git diff --quiet HEAD, which ignores untracked files. The release workflow's checkout-written files (google-services.json, local.properties, the signing key) are gitignored as well, and build-release checks out with fetch-depth: 0, so release builds read as clean. Only the exit code is read, so the configuration cache doesn't invalidate on every edit to an already-dirty tree.
• Bugsnag. GIT_SHA reuses the git rev-parse HEAD value behind bugsnagBuildId; that value and its use as the build UUID are unchanged.
• No SHA. When commitSha is blank, commitLabel is null and the footer falls back to the previous one-line string, now subtitle_appVersionInfoFooterNoCommit.

VersionInfoTest covers the 10-character cut, the * suffix, short and whitespace-padded SHAs, and the empty fallback.