fix(mobile): render the phase sidebar before the list that always wins

[tusharbhardwaj-bk]

The bug

The phase sidebar toggle did nothing on a phone across three attempted fixes. Root cause, finally traced instead of guessed:

HomeScreen has an early return if (threadListV2Enabled) at line 1159, and resolveThreadListV2Enabled returns true unless a device explicitly opted into the legacy list. My phase-sidebar branch sat after that return, so it was unreachable dead code. The preference wrote correctly, PhaseSidebarPane existed and compiled, and nothing could ever render it.

Moved above that return. Verified order in HomeScreen is now: empty state → phase sidebar → V2 list.

ThreadNavigationSidebarPane had the same shape of defect — it renders a thread list from two paths (props.nativeChrome and the fallback) and only the first was gated, leaving the flag half-wired on tablets. Both paths now gate.

Also fixed: the app was not reporting its build SHA

The phone reported 1.0.4 where a fork build must report 1.0.4+bk.<sha7>. That suffix is how docs/operations/bk-mobile-build.md detects client/server version skew, and losing it made every "which build is this?" question unanswerable — which is a large part of why this took three rounds to diagnose.

Cause was mine: to keep expo-constants off the import graph of tests reaching authClientMetadata, I made the manifest read a fail-soft require, which swallowed the genuine read too. Restored the static import (matching every other consumer in the app) and mocked the module in connection.test.ts instead — which is what features/cloud/publicConfig.test.ts already does.

Why none of this was caught earlier

All three failures are the same mistake: code placed somewhere plausible without tracing whether that line executes. Typecheck and unit tests cannot tell existence from reachability, and CI has no device. The only signal was running it on a phone.

Verification this time included reading the return order back out of both files rather than trusting placement.

Verification

245 tests across 26 files, vp run typecheck clean, vp fmt --check clean, fork markers pass. Re-verified after merging current expbkmain.

Model: Claude Opus 5 (1M context), harness: Claude Code in T3 Code.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	13.5 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	7.2 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.7 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	11	—	21	✅
Claude	Total thread wire	—	13.6 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	7.2 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	11	—	21	✅

Baseline: unavailable · PR result: 34c96ff · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 110.4 KiB
• Claude decoded thread snapshot: 111.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.