I'm not an encryption guy so maybe this is a stupid question, but doesn't this mean you can't update the firmware without losing all your encrypted data?
A more ergonomic approach for sealing long-lived data is to use something like a hash chain [0], where the chain starts with the equivalent of a DICE UDS, and the chain's length is (MAX_VERSION - fw.version). The end of that chain is given to firmware, and the firmware can lengthen the chain to derive older firmware's secrets, but cannot shorten it to derive newer firmware's secrets.
This presumes that the firmware is signed of course, since otherwise there'd be no way to securely associate the firmware with a version number. If the public key is not baked into the HSM, then the hash of the public key should be used to permute the root of the hash chain.
If you lose the firmware entirely you would indeed lose the derived decryption keys. But if you keep the firmware somewhere safe (or even fetch it again from wherever you got it first), then loading it again would derive the same keys, and you can decrypt your stuff again.
This makes reproducible builds very important by the way: if you rely on a source control system to hold on to old versions of the firmware (just in case someone needs it to decrypt old files), you really really want a way to re-generate the same binary blob from the same source code.