Part of the Federated Collaboration roadmap (docs/maintainers/federation-roadmap.md). Depends on Story 1 (follow a user + repo aggregation).

Goal

As a user, fork a public repository that lives on another (allowlisted) git-shark instance into my own namespace, so I can push contribution branches and later open a federated merge request against the upstream.

Scope

• Clone a remote repository (by actor URL or handle) into a new local repo in the caller's namespace.
• Persist the upstream link: remote actor URL + remote clone URL (reuse/extend the existing fork parent model; parent is remote, not a local repo id).
• Surface the fork on the repo page as "forked from <remote handle>".
• SSRF discipline: the remote git clone URL is remote-supplied — must go through the same guard class as other outbound federation fetches (RemoteUrlGuard today only covers HTTP fetches; git clone is a NEW outbound surface — flag for security-auditor).

Out of scope

• The merge-request-back flow (Story 3).
• Keeping the fork in sync with upstream (pull/track updates) beyond the initial clone — can be a follow-up.

Notes

• No federated Fork activity is strictly required for v1 — the clone itself works over plain git. A Fork/Create announcement to the upstream is optional polish.
• Test-first: start with a failing test that forks a remote repo fixture and asserts the upstream link is persisted.