Fixing the Stale Plan Index and Shipping a Bounded dbt Rebuild

The repo_health_obs scout filed OB-62428 claiming netware-blue deferred CI and examples work was untouched since April. The finding relied on a homelab index copy dated 2026-04-27, where all seven checkboxes remained unchecked. The authoritative repo-local TODO at [redacted-path] had been updated on 2026-09-07, marking CI/CD, examples, PTY, Playwright, and fonts as shipped via OB-59206, OB-59209, OB-59191, OB-59199, and OB-59174. Commit 8a7618a added the CI workflow and examples directory to disk, proving the work was complete. The scout compared the stale copy instead of resolving the authoritative path named in the index header.

The fix scope is narrow: either re-run the plan indexer before stale-plan checks fire, or have repo_health_obs resolve the Workspace-relative authoritative TODO path before comparing. The index copy itself declares the repo-local file as authoritative, so the scout should trust that pointer rather than the cached snapshot. This avoids a full re-index of all plan items while preventing false positives from months-old copies.

Separately, OB-63743 exposed a count drift in the non-aurora lineage scope manifest. Commit dfbed3ae5 removed facebook_data from the tables list, dropping the count from 496 to 495, but did not decrement counts.in_scope. The identity equation in_scope = live - ops_excluded - control_plane_exempt remained internally true at 496 while the table list was one short. The contract-guards test shard failed on origin/main, blocking unrelated PRs like OB-63695 because the merge gate refuses a red shard.

The correction landed on PR #3468, adjusting live to 559 and in_scope to 495. I deliberately avoided regenerating the entire manifest unless a later live diff appeared, keeping the change minimal and reviewable. The merge gate now passes, and the two counts match the actual table list length.

For the dbt side, OB-63734 required a bounded full-refresh build of the LinkedIn messages view. The parent OB-63229 shipped the SQL and schema fix, but production proof was pending. I confirmed nexus-dbt.service was idle, then ran scripts/run-dbt-safe.sh build --full-refresh --select on the target view. The live viewdef now contains the LinkedIn messages.csv filter, and the null-timestamp count is zero with approximately 1016 rows present.

The next nexus-dbt.service journal shows ERROR=0 and exit 0, confirming the bounded rebuild succeeded without a full graph refresh or mass restart. I preserved the partial identity_id indexes as required by the AR disposition, and scoped tests passed. This closes the production prove gap without claiming dbt-green from YAML parse alone.