ci: auto-prune stale CompatibilitySuppressions.xml entries on baseline bump

[Vulthil]

Summary

• Adds eng/refresh_compat_suppressions.py, invoked by both mark-api-shipped
  and propagate-baseline-to-main right after each bumps
  PackageValidationBaselineVersion (and after nuget.org has indexed the new
  baseline package), so its changes ride in the same commit/PR as the bump.
• Prune-only: regenerates each project's suppressions against the new
  baseline via dotnet pack -p:ApiCompatGenerateSuppressionFile=true,
  redirected through ApiCompatSuppressionOutputFile so the real files are
  never touched until proven safe. Only ever removes entries no longer
  needed; if regeneration would add one anywhere, the job fails with the
  exact entry and modifies nothing -- that means a real API break needs a
  human suppression decision, not a silent auto-suppress.
• Both jobs previously never ran a .NET command: added the shared
  setup-build composite (gated in the propagate job to match its existing
  bumped-skip logic) and fetch-depth: 0 (Nerdbank.GitVersioning's
  shallow-clone warning would otherwise become a hard failure under this
  repo's TreatWarningsAsErrors). Both timeouts raised 35 -> 45 min for the
  added dotnet pack cost.

Verification

• No-op: current baseline + current suppression files regenerate to
  byte-identical files (comments included); nothing written.
• Prune: a planted bogus entry is removed while genuine entries survive.
• Invariant: deleting a still-needed entry makes regeneration want to add
  it back; the script detects that, writes nothing, and fails loudly.
• Deletion: a project whose entire suppression set prunes away has its
  file removed rather than left as an empty shell.
• release.yml parses; each job gained exactly the two inserted steps;
  add-paths on both create-pull-request steps extended so pruned/deleted
  suppression files ride the bump PR.

Backport to v1.0: no — release-automation change on the default branch only.