Volume mounted successfully once via CLI, now fails with "incorrect password" on every retry — password unchanged, file unchanged

[Matthias Ling]

VeraCrypt 1.25.9, Windows 11
Volume: file-hosted container, 200GB (214,748,364,800 bytes exactly), created ~April 2018
Originally created as a TrueCrypt-format volume (old install evidence found alongside: VeraCrypt Format.exe, veracrypt.sys dated 4/1/2018)

What happened:

Volume gave "Operation failed due to one or more of the following: incorrect password / incorrect PIM / incorrect PRF / not a valid volume / TrueCrypt format no longer supported" when trying to mount with recent VeraCrypt.
Ran a PowerShell loop testing password variations via CLI: VeraCrypt.exe /volume X /letter Z /password Y /quit /silent, checking Test-Path Z:\ for success.
One attempt reported success (password: B_lume2_018, no TrueCrypt Mode flag, no PIM, default/autodetect PRF). Mounted to Z:, browsed real, recognizable content matching what should be in the volume (specific named folders), copied one folder successfully before dismounting.
All subsequent attempts — same password, same file, same flags, via CLI, via GUI, with TrueCrypt Mode toggled, with "use backup header" option, on a different drive letter — fail identically with the original error.

What's been ruled out:

File corruption: file size and first 64 bytes of the header are byte-for-byte identical before and after the failures (verified via PowerShell stream read + hex dump).
Password typos/encoding issues: verified every character of the working password string is plain ASCII with no lookalike/invisible Unicode characters.
Stale drive mapping: net use and Get-PSDrive show no pre-existing Z: mapping that could have produced a false positive.
Driver conflict: fully uninstalled VeraCrypt, rebooted, reinstalled clean — no change in behavior.
Disk health: physical disk (Seagate Expansion, external USB) reports Healthy via Get-PhysicalDisk.
Exhausted the full original password candidate list (225 variations around the known base phrase) with reliable /list-based mount verification — no match.

Question:
Is there any known VeraCrypt driver behavior where a previously cached/unlocked volume key could allow a mount to succeed independent of the password actually entered (e.g., cached from an earlier session), which would explain a one-time success followed by consistent failures with an otherwise-unverified password? Or any other explanation for a single successful mount that hasn't been reproducible since, given the header bytes are confirmed unchanged?

Any insight into VeraCrypt's internals here would be hugely appreciated — happy to provide more diagnostic output if useful.