A fork takes an upstream change and offers its own back, proven end to end across two forges #12425

One journey test now walks the fork loop, and it found one gap, which I fixed. Pushed; the new test, test/mcp-size.test.ts, the related MCP and fork-tree tests and tsc pass. bun scripts/gate.ts printed nothing, so I read that as clean without confirming its exit status. The forge's check hasn't run yet.

What changed

• Journey test (test/fork-flow-journey.test.ts, about 4 s, one forge in memory, driven through the following API, the MCP and the forks page):

1. A new fork's tree word is proposes. 2. The fork commits its own work, and a change lands upstream. 3. The following API says diverged, with merges cleanly. One take_updates merges it. 4. The fork offers its work up through the MCP, and asking twice returns the same pull. 5. The upstream owner merges the offer, and the fork then has nothing ahead. 6. The tree word goes follows and back to proposes as the mode changes. The forks page shows the word too.

• Gap fixed: an in-forge fork had no MCP tool to offer its work upstream. propose_to_parent_forge returned no_parent_forge for it. It now calls proposeUpstream when the fork's parent is in the same forge, using the words from follow_words.ts. That is an extension of the existing tool, not a new one, so the MCP size ceilings are untouched. docs/MCP.md and the tool's doc line say so.
• Doc fix: the fork_tree doc now lists the word field, which the JSON already carried.

What I left out

• Two forges: the test runs one forge. A fork of a different forge is a spawned forge. Its offer, proposeToParentForge, is already covered end to end by test/upstream-forge.test.ts, so I didn't duplicate that walk here.
• Silent fast-forward: a fork with no work of its own is moved silently as the push lands, even in proposes mode. A fork has an update line to take only when it has its own work and both sides moved, so the test uses that case. This looks intended, but it is worth a person's glance.
• Gaps filed: none, so there are no issue numbers to list.

Try it Run bun test test/fork-flow-journey.test.ts. Or open /alice/lib/forks on a forge with a fork and see each fork named follows or proposes.

The pre-push hook asked for a Try: commit, so there is an empty commit carrying that line.

This update fixes the failed check on this pull. The gate rule "a comment line is wrapped at 100 columns" flagged line 91 of test/fork-flow-journey.test.ts as 101 characters. I rewrapped that comment, which is the only change; no behaviour changed.

After the fix, bun scripts/gate.ts and bun x tsc --noEmit both pass, and so do the 4 tests in test/fork-flow-journey.test.ts. The gate only passed once the edit was committed, so it appears to read committed files rather than the working tree. I did not run the rest of the suite; the forge runs the full check on this push.

The pull itself is unchanged: the fork-follow flow and its journey test, as in the earlier description. To try it, open /alice/lib/forks and see each fork named as following or proposing.

The check failed because docs/MCP.md was out of date: its tool table had no current row for propose_to_parent_forge. I regenerated it with bun scripts/mcp-table.ts, a one-line change. test/mcp-table.test.ts now passes, 8 of 8 (I ran only that file).

I did not run bun scripts/gate.ts, bun x tsc --noEmit or any other test file; the change touches only the generated doc table. The fix is pushed.