Temporarily disable legacy checker flow + add Sentry observability

[JuanVqz]

Summary

Temporarily disable the legacy GH-Actions checker flow at the API edge so we can isolate whether the new lockfile flow is the source of the production memory leak. Adds Sentry tracking on every disabled endpoint and on the remaining legacy gem pages so we can identify any caller.

Background

PRs #199, #200, #203 and railsbump/checker#40 reduced the leak meaningfully but did not close it. Heroku metrics for the most recent weekend show AVG 873 MB / MAX 1335 MB on web.1 against a 1024 MB quota, with R14 errors firing repeatedly.

On Apr 30 we measured a clean +14 MB step on web.1 RSS for each POST /lockfiles upload that did not reclaim, while quiet windows of pure crawler traffic stayed flat. That points the next investigation at the new lockfile flow.

To make that investigation clean, this PR removes the legacy flow as a confound. The legacy chain runs through:

• POST /api/releases → RailsReleases::Create.perform_async / Gemmies::Process.perform_async
• POST /api/github_notifications → GithubNotification.create! + GithubNotifications::Process.perform_async
• POST /api/results → tail of the GH Actions check pipeline
• The Heroku Scheduler entry running bin/rails runner "Compats::CheckUnchecked.call" every 10 min (must be disabled separately in the Heroku UI; no CLI for that)

After this PR plus the scheduler removal, the only flow producing checker work is Lockfile#run_check! on POST /lockfiles.

Manual steps required after merge

# 1. Remove the Heroku Scheduler entry (no CLI for this addon)
heroku addons:open scheduler -a railsbump-production
# Delete the row "bin/rails runner Compats::CheckUnchecked.call"
# Leave the "bin/rails runner Maintenance::Hourly.call" row alone — it's
# orthogonal (sitemap regen, email notifications, cleanup). One nuisance:
# its check_pending_compats helper will start reporting "compats pending
# for a long time" since CheckUnchecked is off. If those alerts get noisy,
# comment that private method out in app/services/maintenance/hourly.rb.

# 2. Disable the GH Actions checker workflows in railsbump/checker
gh workflow disable check_bundler.yml -R railsbump/checker
gh workflow disable rails_release_sanity_check.yml -R railsbump/checker
# Belt-and-suspenders: prevents accidental dispatches even if the
# scheduler entry is restored or someone calls BundlerGithubCheck directly.
# Re-enable later with `gh workflow enable <file> -R railsbump/checker`.

What this PR is not

Not a fix. The leak measurement points at the lockfile flow; this PR only removes the legacy flow as a possible confound and gives us observability on what is still calling those endpoints. The leak hunt continues in a follow-up PR (planned: per-request memory delta middleware to attribute RSS retention to a specific path).

Test plan

• Deploy to staging, hit each disabled endpoint, confirm 503 + Sentry event arrives.
• Open Sentry → Performance, confirm transactions appear at ~5% sample.
• Remove the Heroku Scheduler entry.
• Watch Sentry inbox for temporarily_disabled messages over 24h to identify callers.
• Watch web.1 RSS curve for slope change vs. last week.

Related

• Probe memory leak: exclude status_determined_by from CheckUnchecked batches #199, Fix: Memory Leak Web #200, Wrap puma and sidekiq with jemalloc.sh #203 — earlier rounds (worker batches, drop :output persistence, jemalloc Procfile wrap)
• Stop sending bundle install output in result payload checker#40 — checker stopped sending :output
• notes/memory-leak-watch.md — full data trail across the investigation

[JuanVqz]

traces_sample_rate=0.05 turns on per-transaction performance traces in
the Sentry UI; profiles_sample_rate=0.05 adds allocation flame graphs
on the same sampled requests. Together they give us per-endpoint
latency and allocation hot spots without manual instrumentation, while
staying well under the free-tier event quota at the app's current
traffic level.