Agreed that for resilient libraries, @const is highly analogous to @frozen. But that doesn't, in my view, translate into an argument that we should bring @frozen into the realm of non-resilient libraries.
I'd view this in the other direction—an exhaustive enum is the underlying concept here, and in situations where source is available, every enum is exhaustive because every compilation is in a sense, independent. I don't think it's really reasonable to call enums in non-resilient libraries "frozen", since they are of course allowed to change, add cases, remove cases, etc.
Agreed, though I'd again shift the framing to "nonexhaustive enums" being the concept that only exists (and is indeed the default) in resilient libraries. Then, @frozen is the way for resilient libraries to recover the (non-resilient default) exhaustive behavior for enums.
Aside from concerns about diluting the seriousness of the promise made by @frozen by bringing it to non-resilient libraries, I think it's just the wrong word to describe what's going on. IMO it fails the same test you mentioned above for @const:
Whereas @const may difficult to distinguish in meaning from the existing "cannot change across a single execution of the program", @frozen goes too far in the other direction and (IMO) expresses "cannot change across multiple compilations of the library." We're looking for a label that expresses something in the middle, roughly, "cannot change across multiple executions of the same compilation of the program."