upload cooperative mode with agent

[jerry-skydio]

Create a model for working cooperatively with a agent that is triggered via external interaction and pushes directly to a revup managed branch. We'll need to make this opt-in as it changes some fundamental behaviors around upload in ways that may have confusing edge cases.

upload gains a "overwrite-mode" option

• default is "force" meaning your local changes in a topic will always steamroll whatever is in the remote branch. this is just current behavior
• dont-overwrite: upload will fail if the remote contains non-self-authored commits that aren't reflected in your local stack. you will be prompted to revup download them. this is generally pretty safe as it will prompt you to keep local and remote in sync. if you routinely squash those changes into your existing commits though this could get annoying
• parallel: upload will recreate any remote commits that aren't authored by you. if you do any squashing or amending both it and you will be very confused. if you strictly commit and never amend this could work
• maybe other strategies could get added?

a workflow would look something like this

• you make a commit and upload a PR, iterate on it a bit
• your buddy fixes something on your PR for you
• you may attempt to upload, but it sees that there is one remote commit that isn't authored by you and you don't have locally (identity by patch id). upload will warn you
• revup download will see that you're configured for dont-overwrite mode, it can pick in this commit for you. it has a squash mode where it integrates it into your last commit. either way it needs to insert some metdata into that message indicating the commit identity it originally pulled in (possibly specifying the patch id literally). you are free to amend if after that point
• if you have retained the metadata from "download", upload won't stop you the next time. otherwise there will be a --force flag so you can get past it (which really is an alias that changes your overwrite-mode to force)

revup download needs to be better specified though. its really a more fleshed out cherry-pick that adapts to what you want to download. it sometimes behaves like amend, sometimes like "revup cherry-pick", sometimes like "git cherry-pick". we need to make sure this isn't too confusing

• you can point "revup download" to a branch or github PR link just like "revup cherry-pick". first off though it needs to (if possible) get past the limitation of cherry-pick where it will bring in the wrong contents if the PR has been retargeted (because the retargeting changes nothing about the actual branch). however it might be possible to infer based on the tip of origin/basebranch. ok after that point it will pick+squash the remote branch and possibly append commit message (vs cherry-pick just getting the first one). Then it inserts some special metadata indicating the details of the arguments it was downloaded with. It will also strip out any "topic" tags so later upload doesn't view it as valid (or have upload purposefully ignore topics with download tags). Further revup downloads (argumentless) will attempt to fetch remote and amend-morph this commit into what the remote now has. This can of course conflict at any stage so we need to bring in actual conflict resolution. you probably should also be able to refer to this somehow (full branch name?). also maybe when specifying just a branch the base can default to your local base?
• you can point "revup download" at a topic name that refers to one of your local topics. it should not be a topic with multiple branch targets because that is confusing. you should not refer to your own topic by github pr. revup download has exactly one function here which is to pick up non self-authored remote commits. should we allow this even if you're not using dont-overwrite?