diag(build): per-build GUID stamp + resolve/blit timing split (take-6 attribution failure)

Take 6 measured render 35-41ms — WORSE than take 5's 25.5 — and the run could
not be attributed to a binary: exe mtime != build contents (incremental builds
serve stale exes; a source edit without rebuild is a silent old binary). Three
takes of a perf saga had been judged against builds nobody could prove.

- ytLive.csproj GenerateBuildStamp target: fresh GUID per compile (writes
  obj/BuildStamp.g.cs -> Helpers/BuildStamp.Id/BuiltLocal). Deliberately defeats
  incremental lies: every 'dotnet build' recompiles the app project.
- Wordmark shows the id as a superscript (TopBar.xaml, x:Static, 9px grey
  BaselineAlignment=Superscript); startup.log records 'Build <id> (compiled
  <time>)' so every take is cross-readable with the visible UI.
- FramePump stats split the tick: 'avg render Xms (resolve Y), avg submit Z' —
  the resolver is timed separately (wrapper resolver on per-tick paths; bake
  keeps the raw one) so take 7 names the hot half of 'render' with data.
- Fixed a latent transition-clock bug found on the way: lastTick now restarts
  every frame (the branch rework had restarted it only during transitions,
  letting a transition begun after idle complete instantly on its first Tick).

ONE integration test family: BuildStampTests (unit: shape) +
BuildStampDisplayTests (RealApp, namescoped FindName on TopBar proves the
wordmark SHOWS the id). 47/47 per-class green, clean build 0 warnings. Docs
same commit. User's top-bar/session spec (re-sent twice) + settled Q&A
decisions folded into HANDOFF Unit B — next work unit after take 7 verdict.

MyMistakes.md

@@ -213,3 +213,18 @@ one-line provenance — *who asked, what triggered it* ("creator: OBS delay-filt
 Features without attribution become roadmap orphans that get punted, removed, or re-litigated. Same
 disease as an unexplained "known failure" label — a fact recorded without its reason is a future
 argument.
+
+## An un-attributed build invalidated three takes of a perf saga — stamp the binary
+
+(2026-09-04, takes 4–6) After each render-perf fix the creator "exed the code" and re-recorded, but
+the exe timestamp ≠ binary contents (incremental builds reuse whatever compiles clean; a source edit
+with no rebuild serves the OLD exe). Take 6 measured render WORSE than take 5 (35-41ms) and there was
+no honest way to tell "the chat cache fix doesn't work" from "the fix was never running" — three
+hours of diagnosis on an unattributable sample. Rule: if takes measure the app, EVERY build carries
+an id and EVERY log line traces to it — `GenerateBuildStamp` (csproj) writes a fresh GUID per
+compile (deliberately defeating incremental lies), the wordmark shows it as a superscript, startup.log
+records `Build <id> (compiled <time>)`. A perf claim without build attribution is a guess; ask for the
+stamp BEFORE theorizing. (Also this session: a sentinel-byte test where the source pattern could
+GENERATE the sentinel, and a fixed-point bilinear that shifted BOTH stages and silently drew nothing —
+see the rawvideo recipe.)
+