monopam: propagate nested-mono push/pull failures + drop pull auto-add
The nested-mono push/pull paths were swallowing inner-subtree failures
as warnings, so a non-fast-forward upstream push or a real merge
conflict in an inner subtree would silently report success. Three
adversarial cram tests now pin the workflow:
- pull_conflict_multi.t: alice and bob each edit two of three files,
bob also adds a fourth; pull must report both content conflicts
and accept the new file cleanly.
- pull_conflict_structural.t: modify/delete + delete/modify + add/add
in one merge; covers the tree-structure code paths the existing
pull_conflict.t never touched.
- nested_mono_conflict.t: bob pushes to lib.git between alice's edit
and her push in the product workspace; the conflict surfaces
through three layers (product -> open-mono -> lib).
Fixes:
- inner_subtree (push) now returns its push error instead of
logging a warning, so non-fast-forward at lib.git stops the run
with exit 4.
- mono_inner / mono_entries collect inner errors and bubble them
up to push.run, which reports the first one as the command exit
status.
- merge_inner_subtree (pull) collects conflicts and returns them so
the outer pull can include them in the Pull_conflict error.
- fetch_or_clone_inner now resets the local checkout to the remote
HEAD instead of just fetching — without this the depth-first
inner pull merges from the stale local checkout (still at the
pre-push commit) instead of the actual upstream tip.
- subtree (pull) returns Skipped when the prefix doesn't exist in
the mono. Pull no longer auto-creates subtrees: that behaviour
interfered with nested workspaces by materialising libraries at
the outer level when they actually live inside a nested mono.
Use [monopam add] explicitly when you want a new subtree.
- run skips Init.write_readme/claude_md/dune_project on the
conflict path so the git-commit subprocess output doesn't
interleave with the CONFLICT log lines.