Enforce blob-type consistency across blob versions

[Copilot]

Azure rejects replacing a versioned blob with another blob type while its current blob or retained versions exist. Azurite previously allowed direct writes and Copy Blob operations to create mixed-type histories.

• Validation

  • Added Loki validation across Put Blob, Commit Block List, and synchronous/asynchronous Copy Blob paths.
  • Checks every committed record for the blob name.
  • Uses the existing 409 InvalidBlobType convention.
  • Revalidates immediately before Copy Blob metadata mutation to close asynchronous race windows.
  • Leaves SQL and versioning-disabled behavior unchanged.

• Data integrity

  • Rejects before archiving, replacing, or inserting metadata.
  • Preserves the current blob, retained versions, and copy source.
  • Allows same-type operations.
  • Allows another type only after deleting the base blob and every version.

• Coverage

  • All six block/page/append direct-write transitions.
  • All six Copy Blob transitions through both copy APIs.
  • Same-type writes and copies.
  • Retained-version-only rejection and recreation after complete deletion.
  • Versioning-disabled compatibility.

• Evidence

  • Azure behavior is based on review feedback in discussion_r3912707687.
  • The exact production error was not recorded; InvalidBlobType follows existing Azurite factory and test conventions.
  • Skipped production-parity tests were analyzed but not executed against Azure.

• Validation results

  • Focused regression suite: 26 passing.
  • Related versioning suites: 122 passing.
  • Related Copy Blob suites: 19 passing.
  • Full local Blob suite: 695 passing, 3 pending.
  • Build, lint, secret scan, and CodeQL passed.