Fall back to full backup when previous step is non-existent

What does this MR do and why?

Fixes server-side incremental backups failing for repositories that were non-existent (existed in the database but had no commits) during a prior backup.

Related: #7207

Problem

When a full backup runs against an uninitialized repository, Manager.Create records the backup as non_existent and returns before writing any ref or bundle blob. The committed manifest still references a ref_path pointing at a blob that was never created.

Once that repository receives commits, the next incremental backup bases its increment on the previous step's ref_path. Reading that missing blob to compute the negated refs fails with doesn't exist, and every subsequent daily incremental keeps failing until the manifest TOML is edited by hand. This blocks the common monthly-full + daily-incremental cadence at scale.

Solution

In ManifestLocator.BeginIncremental, fall back to writing a full backup step instead of an incremental when:

• the previous backup was recorded as non_existent, or
• the previous ref blob is missing from the sink.

The non_existent check also heals manifests already corrupted in object storage, since those carry non_existent = true — no manual TOML remediation required.

How to set up and validate locally

Automated tests (run against system Git if bundled Git isn't built):

GITALY_TESTING_GIT_BINARY="$(which git)"
  go test ./internal/backup/ -run 'TestManifestLocator$|TestManager_Create_incremental' -v

• TestManifestLocator — BeginIncremental falls back to full when the previous manifest is non_existent, and when the previous ref blob is missing from the sink.
• TestManager_Create_incremental — new case previous backup non-existent, repository now initialised drives the full Manager.Create path. Reverting the fix makes it fail with the exact production error (... 001.refs ... doesn't exist), confirming it's a genuine regression guard.

MR acceptance checklist

• Tests added for the new behaviour.
• No manual remediation of existing manifests required.
• Documentation reviewed (no user-facing doc changes needed).