Keep the legacy storage fingerprint for one release

[ppXD]

Summary

• Since Compare storage namespaces by physical location #2105, admission, the agent-run-log bootstrap and the deployment-default materializer stored the hash of the provider's PHYSICAL namespace projection in storage_profile_revision.namespace_fingerprint. The previous build's retention reaper decides whether one object key is one object across teams by comparing that stored column (ArtifactRetentionReaper.cs:469-489 at 583efb0). During a rolling deploy, or after a rollback, it therefore treated a revision admitted for R/ as a different namespace from one admitted for R, and collected another team's live bytes. OSS -internal or https endpoints and an explicit region had the same effect.

• For this release, new revisions store the legacy value again: StorageProfileRules.StoredNamespaceFingerprint calls LegacyNamespaceFingerprint, which matches the 583efb0 algorithm byte for byte. This applies at admission (StorageProfileService.cs:275, which the deployment-default materializer also goes through) and at the agent-run-log bootstrap (AgentRunLogStorageReadiness.cs:81).

  • The physical projection is still computed, so a configuration that reaches no namespace is refused as before.
  • This build's reaper keeps deriving the physical object at sweep time and never decides on the column.

• StorageNamespaceFingerprintBackfillRecurringJob runs every 10 minutes as a thin Job → Command → Service chain. It restores the legacy value on revisions that a physical-identity build already wrote, or that an older pod writes during the rollout. It disables the revision immutability trigger only inside its own transaction and turns it back on before commit, so no migration is needed.

• Follow-up release, not in this PR: switch the stored value to the physical identity once no build that compares the column can run against the database. That change deletes the backfill and must also remove its schedule, because the worker registrar only adds recurring entries and a deleted job class makes every tick fail with JobLoadException. Do one of:

  • call ICodeSpaceBackgroundJobClient.RemoveRecurringJobIfExists("StorageNamespaceFingerprintBackfillRecurringJob") at worker boot, or
  • keep the job class as a no-op for one more release.

  This is documented on StorageProfileRules.StoredNamespaceFingerprint and on the job class.

Test plan

• Unit (StorageNamespaceLegacyFingerprintTests, StorageNamespaceFingerprintBackfillDispatchTests):
  • Golden legacy fingerprints equal the 583efb0 values for every shipped module and config shape, and admission stores them.
  • A configuration that reaches no namespace is still refused.
  • The job dispatches only its command, and the handler is a thin delegate.
• Unit: full suite, 13538 passed and 1 skipped out of 13539.
• Integration, mixed-version (ArtifactRetentionReaperFlowTests.PreviousBuild): the previous build's stored-column comparison, over two revisions this build admitted with different spellings of one root, now says shared, and physically distinct roots still compare as different.
• Integration (ArtifactRetentionReaperFlowTests.Namespaces): this build's reaper behaves as before.
• Integration (StorageNamespaceFingerprintBackfillFlowTests): the backfill restores the legacy value, is idempotent, leaves the table immutable again, and is safe on concurrent workers.
• E2E, Worker surface (StorageNamespaceFingerprintBackfillE2ETests):
  • Triggers the real worker host's registered StorageNamespaceFingerprintBackfillRecurringJob entry through Hangfire.
  • A revision stamped with the physical value is restored, a legacy one is untouched, and storage_profile_revision_enforce_immutability stays enabled.
  • Mutation-checked: the test goes red when the trigger is not re-enabled and when the job dispatches nothing.
• E2E, Worker surface: the recurring-job smoke census is still green.
• E2E, Http surface: StorageNamespaceSharingE2ETests and the rest of CodeSpace.E2ETests.Storage pass (59/59).