fix(app): truncate long project breadcrumbs

[cunninghamcard-bit]

Reproduction

A long project name can consume the toolbar width and collide with the source filter and search controls.

Root cause

The project breadcrumb had no shrink or truncation boundary, while the source-filter control was allowed to shrink.

Fix

• Give only the project crumb a shrinking, trailing-ellipsis treatment and expose the full name through title.
• Keep the source-filter control at its intrinsic width.
• Leave the shared .breadcrumb container unchanged, so SessionDetail, MemoryDetail, and RecapDetail title crumbs are not clipped.

Verification

• npm test: 546/546 passed.
• npm run typecheck: root and app tsconfigs passed (2/2).
• npm run lint: 0 errors, 9 existing warnings.
• npm run test:electron:all: 4/5 suites passed locally; electron-session-virtualization.mjs failed macOS hidden-window wheel/timing assertions. The unchanged origin/main baseline also produced 4/5 in the same environment (virtualization failed with patchReads: 0). No test assertion was changed or loosened.

Scope

This PR only addresses project breadcrumb layout. The source-filter outside-click behavior remains in #116.

[tommy0103]

Verification cross-check from a maintainer machine (macOS, Electron 43.2.0): I built this head (f5dd971) and ran electron-session-virtualization.mjs 3 times — 3/3 fully green (55/55 assertions each).

On the patchReads: 0 baseline failure mentioned in the description: I could not reproduce it here — 5/5 suite runs pass on code identical to origin/main in renderer/preload. It appears environment/timing-specific rather than a stable main-branch defect (the cold-open patch-read assertion is known to be timing-sensitive). Nothing suggests this PR regresses the suite; the change is confined to the toolbar breadcrumb, which this suite never exercises. LGTM on the verification front.