feat(dashboard): custom-section builder saves again — the flagged tree migration

Archaeology, prompted by the user asking when it broke: the builder's
save NEVER worked. The page was born (2026-02-19, a92bf99a) posting
auto_assign_rules as a JSON-encoded STRING into an endpoint that has
bound []Rule since its creation (2026-01-31, 6495cc2c), plus fields
(manual_book_ids, match_type, library_id, show_on_dashboard) the
endpoint never accepted. The preview button hit a real endpoint, so
the page looked alive while Save always failed at request binding.
Verified live before this change: the page's exact payload 400'd
"invalid request" against the unmodified server.

The fix adapts the builder's payload at write time — the legacy rules
vocabulary converts to a filter tree (RulesToFilterTree restored from
the retirement commit as the single write path, unit test restored
with it):

- match_type seeds the converted tree's root mode (any default).
- manual_book_ids attach to the created collection after create
  (unparsable ids skipped — the AddBooks leniency).
- show_on_dashboard persists (new create field).
- Converted trees validate under ParseFilterTree: an unhonorable rule
  is a 400 at write naming the problem, never a stored 500 at render.

Dashboard sections: smart user sections now evaluate their tree LIVE —
GetUserCollectionItems merges stored membership with the composed
engine's matches (deduped, library-scoped, capped at the section
limit). This exposed a REAL production wiring bug: every production
NewDashboardService call omitted the search service, so tree
evaluation through the dashboard could never have worked (the test
harness wired it correctly — the gap was production-only and latent,
because nothing in the dashboard evaluated trees before this
migration). The dashboard handler and both inline sites now receive
the search service, and evaluation failures log instead of silently
emptying a section.

Supersedes the same-day loud-400 stance for the builder's payload
(contract_pins migration entry); custom-section-builder.md documents
the save contract; the create_collection API doc gains the adapted
fields. New TestCustomSectionBuilderSave/BadRule pin the payload →
tree → dashboard-render path end to end. Full container suite green
(155s).

docs/contract_pins.md

@@ -577,3 +577,29 @@ KEPT (live consumers): `POST /api/collections/preview` still accepts
 `rules` and evaluates them in memory (the custom-section builder's
 preview button); `include_auto` on the list stays (the Android app
 sends it). The builder's SAVE remains the flagged §12 tree migration.
+
+## 2026-10-31 — custom-section builder save: the flagged tree migration lands
+
+Supersedes the same-day retirement entry's loud-400 stance for the
+builder's payload. `POST /api/collections` now ACCEPTS the builder's
+shape and adapts it at write time:
+
+- `auto_assign_rules` (JSON-encoded array — string or bare) converts to
+  a filter tree via the restored `RulesToFilterTree`; converted trees
+  validate under `ParseFilterTree`, so an unhonorable rule is a 400 at
+  write naming the problem.
+- `match_type` seeds the tree's root mode (`any` default).
+- `manual_book_ids` attach to the created collection after create
+  (unparsable ids skipped — the AddBooks leniency).
+- `show_on_dashboard` persists (new create field).
+- `library_id` remains selection context only (not stored).
+
+Dashboard sections: smart user sections evaluate their tree LIVE —
+`GetUserCollectionItems` merges stored membership with the composed
+engine's matches (deduped, library-scoped, capped at the section
+limit). This exposed and fixed a real wiring bug: every production
+`NewDashboardService` call omitted the search service, so tree
+evaluation through the dashboard could never work (the test harness
+wired it correctly — the gap was production-only). The dashboard
+handler and both inline sites now receive it, and evaluation failures
+log instead of silently emptying a section.