bug(799): render breadcrumb lineage below the archive root and unify suggestion-path projection

[drmoisan]

Summary

Breadcrumb suggestion and search-result rows rendered the ancestor chain from the mailbox root, so a
row for a folder three levels below the archive root showed the store and Archive segments before the
segments the user cares about. Separately, four archive-root stripping sites had drifted apart, and one
of them stripped a single leading separator when the archive root was empty.

This change trims the ancestor chain at the archive root inside the hierarchy provider, which is the one
seam both the QuickFiler item view and the Efc view route through, and collapses the drifted stripping
sites onto a single shared projection built on ArchiveStemContract.TryMakeArchiveRelative.

Closes #799.

What changed

• Two new production types. ArchiveStemProjection is the shared display projection; ArchiveChainProjection
  is the chain trim. Both are covered at 100 percent line and branch.
• OutlookFolderHierarchyProvider gains the trim, an optional root-accessor constructor parameter of
  delegate type, an error log plus single-segment fallback when a chain does not pass through the archive
  root, and a per-instance absence gate published through a small new interface.
• FolderPredictor delegates the suggestion and recents projections to the shared projection, and the
  empty-root one-separator strip is eliminated.
• BreadcrumbBridgeRouter projects the Efc score paths so archive-rooted suggestions keep their
  percentage, and suppresses zero-candidate rows on the Efc surface.
• QfcItemController gains a new partial that receives the relocated breadcrumb pipeline helper.

The archive-relative stem remains the filing target and the score-lookup key, so the issue 439 constraint
is preserved and all ten of its tests pass unmodified.

Two deviations from the specification's own prose, both pre-authorised and recorded

Row suppression is delivered on the Efc surface only. The QuickFiler presented row set is composed
entirely inside a file owned by a concurrently running sibling item, and at the point the QuickFiler
handler hands its row model to the viewer no provider resolution has been attempted, so the zero-candidate
classification does not exist there yet. Producing it would have required a second synchronous resolution
pass on the UI thread, duplicating the router's work and changing the very ordering the sibling owns. The
specification's decision D-B pre-authorises this escalation; the QuickFiler surface keeps today's fallback
rendering, and the logging half is delivered on both surfaces because it lives in the shared provider.

The projected score is added alongside the raw score rather than substituted for it. The join index
assigns through its indexer, so a substitution would have fixed the stem-presented case and silently broken
the rooted-presented case, whose test does not assert the percentage and would therefore have stayed green
through the regression.

Verification

Full toolchain, one unbroken pass with zero restarts:

Gate	Exit	Result
dotnet tool run csharpier check .	0	Checked 1601 files, no drift
analyzer gate, /t:Rebuild	0	0 Warning(s), 0 Error(s)
nullable gate, /t:Rebuild	0	0 Warning(s), 0 Error(s), zero CS86
coverage test run, nine assemblies	0	7085 of 7085 passed

Regression discipline was fail-before then pass-after: Phase 1 left 33 tests deliberately red and Phase 2
turned all 33 green, with full suites moving from 4786 to 4816 and from 1363 to 1370 and NEWLY-FAILING: NONE.

Coverage did not regress. On the pinned first-party comparability index, line moved 84.55 to 84.58 and
branch 79.24 to 79.28, with PACKAGES_MATCHED=9 on both sides. Of 135 executable changed lines, none has
lower post-change hits than baseline; the four zero-hit lines were checked against the baseline document
and were already zero before this change.

The change footprint is exactly the 20 paths the plan declared. Six files owned by a concurrent sibling
item, and the two issue 439 router test files, were each queried individually and carry no hunk.

Review outcome

Feature review returned PASS with zero blocking findings and seven non-blocking observations. All eight
acceptance criteria evaluate to PASS.

The one finding worth scheduling is non-blocking and is tracked separately rather than fixed here, because
its two sites are outside this change's declared write set: the recents projections read the archive root
through a getter that throws when the root is unresolvable, so the combination of zero suggestions and a
non-empty recents list is a newly exposed throw path. Follow-up: #801

Notes for the reviewer

The branch merges origin/main at 2085504e, which brought in a cohort sibling whose declared change
surface overlapped this one. That merge is the base for every anchored diff and coverage comparison in the
evidence, so the figures measure this item's own footprint rather than the sibling's merged work.

Manual validation against a live Outlook profile has not been performed; the specification states explicitly
that it does not gate the automated review.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MS8fb2wX1Sx1bG67LAr41e