The forge always answers 201 Created for a successful dependency
removal, but the generated forgejo-api client only treats 200 as
success for that endpoint, so every successful removal surfaced as
ForgejoError::UnexpectedStatusCode(201). apply_and_verify caught this,
read the dependency list back, saw the edge was gone, and printed a
"converged despite a reported error" warning — appropriate for a
genuinely unpredictable anomaly, but this mismatch is deterministic and
not a real problem.
Treat that specific status as success outright on the remove path
instead of routing it through the read-back/warning path. The add
path's different, genuinely intermittent 500-despite-success quirk is
untouched, and a real remove failure still goes through the read-back
and still surfaces if it does not converge.
Closes#4531
dep_meta's comment records a measured 404: leaving owner/repo as None
made every same-repo dependency fail, because forgejo resolves the
dependency's repo from the request BODY rather than the URL. Nothing
stopped a later tidy-up from simplifying them back to None.
index() promises "error instead of wrapping". A wrap would not fail
loudly -- it would hand the forge a negative index it looks up as some
other issue.
