Traffic-Based App Rewards: Resolve bootstrap errors

[adetokunbo]

Corrects the bootstrap logic in the ingestion pipeline to remove the potential causes of flakes in the TrafficBasedRewardsTimeBasedIntegrationTest

Fixes #6463
Fixes #6499

The firstSV bootstrap creates the app activity meta row before the sequencer serves traffic, which conflated round completeness metadata with the traffic summary enforcement boundary. This caused spurious NoTrafficSummaries errors on subsequent verdict batches.

Additionally, earliestRound used a fallback chain where lastArchivedRoundO could shadow the -1 bootstrap when verdict ingestion lagged behind the reference store, permanently excluding round 0 from the completeness range.

Changes:

• Make started_ingesting_at nullable (V073 migration). The meta row is created with NULL during bootstrap; updateStartedIngestingAtIfNullDBIO populates it when the first batch with traffic summaries arrives. This a metadata-only change in PostgresSql, which should make it possible to apply without truncation
• Make earliestRound unconditionally -1 for firstSV, matching the existing unconditional override on lastArchived.

The hardcoded -1/0 will be generalized to initialRound - 1/initialRound for non-zero round bootstrap in PR #6000 (de29752a87). That commit adopts the if/else pattern from this PR on rebase.

Pull Request Checklist

Cluster Testing

• If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If an upgrade test is required, comment /upgrade_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a logical synchronizer upgrade test is required (from canton-3.5), comment /lsu_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

• Include any change that might be observable by our partners or affect their deployment in the release notes.
• Specify fixed issues with Fixes #n, and mention issues worked on using #n
• Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

• Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).