On a fork, the page manifest offers its writer how it follows its parent: read it, take the parent's updates, propose its changes up #7856

Intent: good changes bubble up and updates flow down through the fork tree. An agent reading GET /api/v1/here?path=/owner/fork (or MCP here) on a fork should find those moves without being taught. Today the manifest lists none of them, though src/http/api/following.ts serves them all.

Done when:

• [ ] repoActions in src/actions/here.ts adds three actions when the repository is a native fork (forkParentId !== null, origin === null) and the viewer may write it with a read-write credential:

- {do: "read how it follows its parent", http: "GET {r}/following"} - {do: "take the parent's updates", http: "POST {r}/following/take"} - {do: "propose its changes to the parent", http: "POST {r}/following/propose-parent"}

• [ ] Each route is the one the API answers, and each rule is the one that route asks. Check this against src/http/api/following.ts before writing it.
• [ ] A reader of the fork, a signed-out visitor, a read-only token and a repository that is not a fork see none of them.
• [ ] test/here-manifest.test.ts gains cases for a writer of a fork (all three listed), a reader of it (none) and a writer of a plain repository (none). Each fails without the change.

Files: src/actions/here.ts, test/here-manifest.test.ts Risks: #7854 also adds an action in repoActions and cases in the same test. Keep yours in its own block after the participant actions, so the two merge cleanly whichever lands first.