feat(collections): new podcast smart collections are BORN reversed

Per user request, same shape as 0e29eff7 — a default flip, no internal
logic changes: POST /api/collections with an episodes-scope filter_tree
now seeds view_settings.chain_order = "reverse" on the new row, so the
collection lands with "Feed order (reversed)" selected in the detail
header's dropdown and the chain/page order follows the stored value as
if picked. Books-scope smart collections and statics get nothing
seeded; an explicit client chain_order is never clobbered; existing
collections are untouched (the seed exists only at creation).

Pins: TestSmartCollectionBornReversed (episodes seeded, explicit keep,
books-scope and static no-seed); TestEpisodeCollectionsFilterTree's
native expectations flip to the born-reversed reality (changelogged).
One misplaced pin from 81e54f89 corrected: the API envelope's match
list is not chain-ordered and never was — order pins live on the SSR
page and reader chain.

docs/contract_pins.md

@@ -668,3 +668,20 @@ page list + dropdown (`podcastOrderForFeed`), the player's feed chain
   feed position 1 plays LAST for an unset feed; the podcast page's
   dropdown renders `reverse` selected (TestPodcastPlayerOrderControl,
   replacing the former native pin).
+
+## 2026-11-01 — new podcast smart collections are BORN reversed
+
+`POST /api/collections` with an EPISODES-scope `filter_tree` seeds
+`view_settings.chain_order = "reverse"` on the new row (merge semantics:
+an explicit client `chain_order` is never clobbered). The dropdown's
+default selection and the chain/page behavior come from the STORED
+value — no resolution-logic changes; books-scope smart collections and
+statics get nothing seeded; existing collections are untouched.
+
+Pinned (TestSmartCollectionBornReversed): episodes seed, explicit-keep,
+books-scope no-seed, static no-seed; TestEpisodeCollectionsFilterTree's
+born-reversed chain/page pins replace the former native expectations
+(which changelog here per the expectation-change rule). One misplaced
+pin from 81e54f89 was corrected while flipping: the API envelope's
+match list is NOT chain-ordered and never was — order pins live on the
+SSR page and the reader chain.