No mr rebase: fast-forward-only repos rebase by hand #175

A repository with require_signed_commits accepts only fast-forward merges (internal/control/mr.go:961), so every merge request whose target has moved must be rebased locally, force-pushed, and merged again. mr has retarget but no rebase.

The message the refusal prints already spells out the manual procedure:

<repo> requires signed commits, so only fast-forward merges are allowed;
rebase <source> onto <target> locally, re-push, and merge again

That is mechanical, and it is what a person does six times in a row when landing a stack of merge requests. It is also entirely client-side work: replay the branch onto the target in a local clone, signed by the user's own key, push, then the existing fast-forward merge. No server-side signing key is involved, so the rule in the wiki's Threat-Model — the server never vouches for a commit it did not receive already signed — is untouched.

The same shape would give squash its meaning back on a signed repository: collapse locally, sign with the user's key, push, fast-forward. Worth deciding whether both land as one command with a strategy flag.

The cost to weigh: the CLI stops being a thin passthrough to a control command on this one path, since the git work happens on the client. repo fork and friends all run server-side, so this would be the first exception.