Let a story go two ways at once

Attempts pile up at the tip as leaves and cost nothing. The moment the
player takes the story down one the line has already moved past, the two
futures have to coexist — so `tree.fork` gives that attempt a branch of
its own, forked at the depth just before it, and the line it leaves
keeps every turn it has.

One row is inserted and one row is moved. Nothing is copied: everything
before the fork is borrowed through the lineage cached on the branch
row. Measured on a 40-turn story forked twenty times — 21 branches, 140
rows, an 80-action story — the page load costs 31,652 B against the
31,433 B the same story flat costs, and a branch is 103 B of ancestry.

Nothing derived moves either, and that is the part worth keeping: a
memory hangs off the coordinate the parent's attempt still occupies, and
the lineage caps the parent one depth short of it. The fork simply
cannot see it, so it resummarizes that ground from the text it actually
tells, without a line of bookkeeping.

Two things had to change underneath. A new node's depth now comes from
the tip of its branch rather than from the adventure-wide `index`, which
would have left a hole in a fork's path the width of the other branch.
And undo stops at the fork — the turns before it belong to the branch
this one grew out of.

`GET /branches`, `POST /branches/{id}/switch` and
`POST /actions/{id}/fork` are the endpoints SP7's tree view is drawn on.

365 tests green, 18 of them new in test_branch_forking.py.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017Dvvqn9ZDR4ixeFPHNbww7

backend/tests/test_branch_clause.py

@@ -1,8 +1,11 @@
 """Phase 14 SP2 — a read sees one story, and knows which one.
 
-Nothing in the product forks yet, so these tests build the fork by hand: three
-branch rows and their nodes, written straight to the database, arranged as the
-design doc's own worked example.
+These tests build the fork by hand: three branch rows and their nodes, written
+straight to the database, arranged as the design doc's own worked example. That
+was the only way to build one when this file was written (nothing forked until
+SP5) and it stays that way now that `tree.fork` exists — a fixture that agreed
+with the code under test could not catch it being wrong. The two are checked
+against each other in `test_branch_forking.py`.
 
     branch C, tip at depth 7, lineage [(C, 7), (B, 5), (A, 3)]
     → A0 A1 A2 A3 B4 B5 C6 C7