SBOM report is destroyed before re-scan; a failed SBOM regeneration loses the prior SBOM

[Vad1mo]

The SBOM scan path still uses delete-then-recreate in MakePlaceHolder, so a failed SBOM regeneration leaves the user with no SBOM and no SBOM accessory until a later successful scan. This is the same destructive-on-failure behavior that #23310 / #23319 fixed for vulnerability reports, but SBOM was intentionally left out of scope there, which widens the asymmetry between the two report types.

Detail

src/pkg/scan/sbom/sbom.go MakePlaceHolder calls delete() (which removes the prior sbom_report row and deleteSBOMAccessory removes the accessory) before the new scan runs. If the new SBOM scan fails, the previous good SBOM is already gone.

By contrast, after #23319 the vulnerability handler reuses the existing scan_report row, so a failed vuln re-scan preserves the last-good report (src/pkg/scan/vulnerability/vul.go MakePlaceHolder).

Proposed change

Bring SBOM to parity: refactor SBOM MakePlaceHolder to reuse the existing sbom_report row (stable UUID) instead of delete-and-recreate, and defer accessory replacement to PostScan/GenAccessoryFunc (which already overwrites by tag). A failed SBOM re-scan would then keep the prior SBOM, mirroring the vulnerability fix.

Note: SBOM does not have the report_vulnerability_record growth problem (no join table), so this is a data-availability/consistency improvement, not a storage fix.

Severity

Low: SBOM regeneration failures are uncommon and recoverable by re-scanning, but the inconsistency with the vuln path is worth closing.

Follow-up to #23310 / #23319.