Let a push ask the server to rebase instead of merge

[jochenhz]

Stacked on #2 — base branch is fix/push-reparent-only-on-rewrite. Review that one first; this PR's diff shows only the rebase work once #2 is merged.

Integrating a push whose parent is no longer the branch head already applies the incoming revision's changes onto the head — a three-way diff against the revision's own parent, applied to the head's state:

state::apply_tree_changes(repository, state_current, &diff_result.changes)
state_current.set_parent_self(current_head);
state_current.set_parent_other(incoming_revision);   // ← the only thing making it a merge

So the machinery for a rebase is there. This adds a rebase flag to BranchPushRequest that asks for the other shape: same diff, same conflict handling, but the result records only the head as its parent, so the branch stays linear.

lore push                        → refuse on divergence      (unchanged)
lore push --fast-forward-merge   → integrate as a merge      (unchanged)
lore push --rebase               → integrate as a rebase     (new)
lore push --rebase --fast-forward-merge → error

Design notes

Mutually exclusive, not ordered by precedence. The two ask for different histories, and quietly applying one would leave the caller unable to tell which it got. Rejected in three places because each has callers the others do not see: clap (conflicts_with), branch::push for embedders that never touch the CLI, and the v1 handler for anything arriving on the wire.

rebase does not imply fast_forward_merge. A server that predates the field ignores it, sees a push with no integration opt-in, and soft-rejects. That is the point: a client asking to rebase must never be answered with a merge it did not ask for. The client turns that refusal into a message naming the likely cause, since a server that did understand the field would have rebased or reported conflicts instead — so the refusal is diagnostic.

Metadata. A rebase is stamped rebased-on-push rather than merged-by / fast-forward-merge. Nothing was merged, and a reader should not meet a "merge" with no second parent.

What it gives up, stated in try_integrate_onto_head: merging keeps the pushed revision reachable as a second parent, which is also what lets the next revision of the same push use it as a diff base. Rebasing drops it, so it survives only as long as the store holds it — long enough for the rest of that push, not beyond.

Verification

contrib/repro-push-reparent-drops-work.sh (from #2) grew a MODE=rebase arm. Run against a server built from this branch and against the released 0.9.0 server:

	result
new server, --rebase	OK — all files present, history is linear: no merge revision (revisions 1‑4)
new server, --fast-forward-merge	OK — merge shape unchanged
0.9.0 server, --rebase	REFUSED — "the server did not perform the rebase…", A's file untouched, nothing merged
both flags	error: the argument '--rebase' cannot be used with '--fast-forward-merge'

cargo test -p lore-revision green (700+ tests). cargo fmt --check and cargo clippy clean for the touched crates. Protobuf bindings regenerated with protoc 36.1; the diff is a pure addition.

Not covered

• No test inside this repository, same reason as lore-revision: Only follow a parent the server renumbered #2: the path needs a client pushing against a live server and there is no harness for that here. The script under contrib/ is what I have.
• Links and layers go through the same loop and are passed rebase: false from their call sites, so their behaviour is unchanged — but the reproduction does not exercise them.
• The deprecated model.proto request has no rebase field; that handler always merges. Intentional, but worth a maintainer's eye.
• GC interaction. A rebased revision leaves the pushed revision unreachable from the branch while it is still needed as the diff base for the rest of the same push. It is in the store, so this works — but it is an implicit assumption about GC not collecting mid-push that deserves a decision rather than my inference.
• Whether this wants an LEP rather than a PR is your call; I did not file one.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}