[TEST] bugfix/indexed-commit-display — resolve bytebell ls commit display

[Dorivika]

What changed

• Added shared commit metadata helpers to validate and normalize indexed Git commit hashes.
• Updated /api/v1/repos response shaping so legacy commitId: "latest" values do not leak into bytebell ls.
• Updated bytebell ls and repo selector details to display the resolved indexed commit SHA instead of trusting raw source.commitId.
• Updated GitHub pull no-op logic to use the same resolved indexed commit and normalize target SHAs before comparing.
• Added write-side guards so invalid GitHub commit values such as "latest" cannot be persisted through setKnowledgeCommit or upsertKnowledge.
• Added focused Bun tests for legacy "latest" metadata, mixed commit history shapes, invalid hashes, uppercase SHAs, dedupe, and empty/missing commit history.

Why

Fixes #55.

bytebell ls could show latest as the indexed commit for GitHub repositories. The issue was in the metadata/listing path: consumers trusted source.commitId directly, so a stale sentinel value like "latest" was rendered as if it were a real commit.

The fix makes commit display resolve only from valid 40-character Git SHAs. If commitId is invalid, ByteBell falls back to the newest valid SHA in commitHashes. Existing metadata is repaired at read time without requiring a Mongo migration, and future invalid writes are rejected.

How to test

1. Install dependencies:

   bun install

The base branch was changed.

[Dead-Bytes]

@Dorivika i am merging this on our testing branch for further testing and then will raise PR on main