docs: record that breadcrumb_relief needs no dropdown-style fix

Audited it the same way as 751d183, expecting the same defect. It is not
there, and the reasons are worth writing down before someone "fixes" it for
symmetry.

The depths already agree with Breadcrumb::paint. The helpers derive depth
from the height they are handed, which is what bit the dropdown; here all
three are handed the widget's own values — well from rect.height, plate from
rh, seams from the run as host. That last one is the non-obvious agreement:
the widget engraves the seams at the RUN's depth, not the well's, and
`PageContent::groove` reproduces that by taking the run as its host. Nothing
is pre-expanded, so nothing drifts.

The rect is fresh too. All three pages build it as a literal one line after
laying the breadcrumb out, instead of reading it back off the widget, so the
previous-frame staleness e256b55 fixed cannot occur.

The window_pc-vs-pc placement is likewise inert, despite dropdown_relief
warning about it: display_list emits all of a PageContent's rects before all
of its reliefs, so call order within pc cannot matter, and only a different
PageContent could reorder anything. Verified by injection what the
breadcrumb actually puts under its carve — hovering a segment moves pixels
in (199,30)-(378,66), so there IS a quad, but it is the 6% hover wash, which
paint() insets to the seam's furthest lean precisely so it never crosses a
boundary. It therefore does not overlap the grooves, and moving the carve
would buy nothing.

No behavior change; comment only.

 src/pages/mod.rs | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/src/pages/mod.rs b/src/pages/mod.rs
index 098bab7..a1ff07a 100644
--- a/src/pages/mod.rs
+++ b/src/pages/mod.rs
@@ -43,6 +43,28 @@ impl Page {
 /// `render_widget` drops the relief prims `Breadcrumb::paint` emits, so every
 /// page that shows a breadcrumb has to carve it app-side — this is that carve,
 /// in one place, since all three pages want it identically.
+///
+/// **Audited against `Breadcrumb::paint` and deliberately left page-side** —
+/// it does NOT need [`dropdown_relief`]'s treatment, for two reasons that are
+/// easy to assume away:
+///
+/// - *The depths already agree.* Each `relief_*`/`groove` helper derives depth
+///   from the height it is handed, and all three here are handed what the
+///   widget uses: the well from `rect.height`, the plate from `rh`, and the
+///   seams from the run as host — the widget engraves the seams at the RUN's
+///   depth, not the well's. Nothing is pre-expanded, so nothing drifts the way
+///   the dropdown's ring did.
+/// - *The rect is fresh.* Every caller builds it as a literal on the line after
+///   laying the breadcrumb out, rather than reading it back off the widget, so
+///   there is no previous-frame rect to pick up.
+///
+/// Nor does the `window_pc`-vs-`pc` split matter here, though `dropdown_relief`
+/// warns loudly about it. `display_list` emits ALL of a `PageContent`'s rects
+/// before ALL of its reliefs, so the call order within `pc` is irrelevant; only
+/// a different PageContent could reorder these. The only quad the breadcrumb
+/// puts under the carve is the hover tint, and that is inset to the seam's
+/// furthest lean by construction, so it does not overlap the grooves. Moving
+/// this carve to `window_pc` would buy nothing.
 pub fn breadcrumb_relief(
     pc: &mut PageContent,
     breadcrumb: &cce_ui::widget::Adapted<cce_ui::widget::Breadcrumb>,