test/docs(404): add unrelated-edit round-trip test; correct MultiCollection-only rationale

Review + live-E2E follow-ups (no behavior change):
- Add a test proving the canonical silent-reset trap directly: a rename-only save
  round-trips both weights untouched (the prior test only edited the weight it
  asserted). Cold review nit.
- Correct the rationale in itemRules.ts + decisions.md: WeightedShuffle is
  MultiCollection-only in the SPA for *meaningfulness* (per-source weights need
  2+ sources), NOT because the classic write path rejects it — live-E2E confirmed
  the classic engine ACCEPTS it on a plain Collection (200) and degrades to
  fair-share. The rejection is on the separate playlist/block write paths, whose
  editors keep their own order lists and already omit it.

Live-E2E (real API): weighted multi-collection create + read round-trips weights;
rename-only PUT preserves them (no silent reset); WeightedShuffle persists on a
classic MultiCollection schedule item. Ratio itself is pinned by the existing
PlayoutBuildGoldenTests.Classic_weighted (3:1), untouched by this SPA change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/decisions.md

@@ -1956,10 +1956,13 @@ is purely SPA (+ docs).
   classic schedule item's Playback Order options. Putting weights on the schedule item was rejected: the same
   multi-collection can be referenced by many schedule items, and weights are shared, not per-reference.
 - **`WeightedShuffle` is offered ONLY for `collectionType === 'MultiCollection'`** (`itemRules.ts`
-  `MULTI_COLLECTION_ORDERS`). It needs per-source weights, which only exist on multi-collection members, so it
-  is meaningless on the single-source collection types — and the classic write path *rejects* it for
-  playlist/block items (decisions.md 2026-07-17), so offering it there would only produce a 400. This is the
-  SPA mirror of that write-path gate.
+  `MULTI_COLLECTION_ORDERS`) — a *meaningfulness* scope, not a rejection mirror. Weights only exist on
+  multi-collection members, so the order only does something with 2+ weighted sources; on a single collection
+  the classic engine still **accepts** it (verified by live-E2E: `PUT /schedules/{id}/items` with a plain
+  Collection + `WeightedShuffle` → 200) but it degrades to fair-share (≈ `Shuffle`), a confusing no-op — so
+  the SPA doesn't offer it there. The *rejection* the #70 entry describes is on the separate **playlist and
+  block** write paths (different engines); the playlist/block editors keep their own order lists (not
+  `MULTI_COLLECTION_ORDERS`) and already omit `WeightedShuffle`, so nothing extra was needed there.
 - **`WeightedShuffle` joins `ShuffleInOrder` in the `fillWithGroup` exclusion.** `fillWithGroupModeEligible`
   already excluded `ShuffleInOrder`; WeightedShuffle is excluded for the same structural reason —
   `PlayoutBuilder` splits a fill-with-group item into per-group enumerators scheduled one group at a time,