release-25.2: backup: fix race condition in starting compaction job

[blathers-crl]

Backport 1/1 commits from #150169 on behalf of @kev-cao.

---

In #145930, scheduled compactions are blocked from running if another compaction job is running for the schedule. However, it is currently possible for there to be a race condition which results in a compaction job being unable to find an incremental backup. Take the following circumstance:

1. Compaction job A starts.
2. A scheduled backup B completes and begins considering whether a compaction job should run. It fetches the current chain to its end time and finds that it should run a compaction.
3. Compaction job A completes.
4. B starts a transaction to create the compaction job. Because A has completed, it does not block the job from being created.
5. B creates a compaction job C that has a start time that is now skipped due to A's completion.
6. When C is picked up by the job system, it resolves the backup chain again, which now no longer has its start time and it fails.

This is resolved by opening a transaction before fetching the backup chain to check for an already running compaction job ID.

Fixes: #149867, #147264

Release note: None

---

Release justification:

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that the change does not break backwards compatibility and otherwise complies with the backport policy. Include a brief release justification in the PR description explaining why the backport is appropriate. All backports must be reviewed by the TL for the owning area. While the stricter LTS policy does not yet apply, please exercise judgment and consider gating non-critical changes behind a disabled-by-default feature flag when appropriate.

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is