fix(work-task): say why a push-back was refused instead of guessing

A push-back that failed reported "git push failed — pushing to a fork
needs its author to allow edits from maintainers on the pull request" on a
pull request where maintainer edits were already allowed. Neither half of
that sentence was earned.

The reason was thrown away one frame earlier. `classify_remote_git_error`
files git's whole stderr under `detail` and leaves `message` as the bare
"git push failed"; `AppCommandError` renders as `{message}` alone, so the
`to_string()` in the delivery path dropped the only part that said
anything. Flatten with the detail instead — the delivery error string is
the sole channel to a human here, and it was carrying no information.

The advice was a fixed suffix, appended to *every* fork push failure. It
described the most common cause, which reads as a finding rather than the
guess it was, and sends a reader to check a setting that may well be
correct. It now depends on what git actually said: a permission refusal
keeps the maintainer-edits hint, a non-fast-forward gets told the branch
moved, and anything unrecognised gets no advice — an unhelpful message
costs a moment, a confident wrong one costs an afternoon.

Permission is matched before staleness, because a forge that refuses a
push outright can also print "rejected", and mistaking that for an
out-of-date branch would send someone rebasing for nothing.