fix(ci): stop all-contributors bot from stripping contributions

[JesperDramsch]

Problem

The pr-sort.yml workflow has been opening PRs that strip existing contributors down to a single conference contribution (e.g. @JesperDramsch went from 17 contribution types to just ["conference"] in .all-contributorsrc, README.md and CONTRIBUTING.md). This produced the bad PRs #371 and #379 (now closed).

Root cause

The "Create branch and make changes" step ran an unconditional all-contributors add <user> conference before the jq guard that was added to prevent exactly this:

if [[ -n "...contributor" ]]; then
  pixi run install
  pixi run add <contributor> conference   # ← unconditional, runs every time
  CONTRIBUTOR=...
  if ! jq -e '... index("conference")' .all-contributorsrc; then   # ← guard
    pixi run add "$CONTRIBUTOR" conference
  else
    echo "...skipping..."
  fi
fi

all-contributors-cli replaces a contributor's entire contributions array when re-adding a type they already have. So the unconditional call collapsed the array on every run; the guard then read the already-stripped file, saw conference present, and skipped the second add — silently defeating the fix.

Fix

Remove the unconditional add. The jq guard is now the only add path: it skips contributors who already have conference and adds only genuinely new contributors. The guard logic itself was verified correct (jq index returns 0/truthy for existing, exits non-zero for new).

No behaviour change for new contributors; existing contributors are no longer corrupted.

Notes

• Also affects the workflow_dispatch manual path (same code), so this one change covers both triggers.
• Optional follow-up (not in this PR): replace the pattern-based bot deny-list in the job if: with github.event.pull_request.user.type == 'User' for a more robust bot check.