The #8331 transient-download regression test failed on every scheduled
run since it landed (abortedResolutionGets stayed 0). The CI trace shows
why: B's pre-upload download is correctly stripped and B's upload IS
rejected CONFLICT_CONCURRENT, but the ops-upload conflict comes back as
HTTP 200 whose body piggybacks the conflicting remote op in `newOps`.
The client LWW-resolves the conflict from that piggyback in-place, so
RejectedOpsHandlerService never issues the separate resolution-download
GET the #8331 fix guards — the path the test arms and aborts.
Fix: the route handler now also forwards B's upload POST to the real
server (keeping the rejection server-computed) and strips
`newOps`/`hasMorePiggyback` from the response. With no piggybacked ops,
the client falls back to the resolution-download GET, which the test
aborts — exercising the guarded catch. A new `strippedConflictPiggybacks`
guard asserts this fired. This stripped-piggyback condition is real in
production when the conflict falls beyond PIGGYBACK_LIMIT (500 ops).
No product code changed; behavior under test is unchanged.
