That pattern reads like activation seat exhaustion rather than anything failing on the machines themselves.
In a VDI or Citrix deployment licences are counted per instance, and the key carries a fixed number of concurrent activations. If your non-persistent instances come back with a different SID, MAC or hostname, each one looks like a new PC and takes another activation off the key.
Nothing returns those seats unless the instance is deactivated before it goes away. A weekend restart of all 120 machines consumes a batch that never comes back, which fits what you saw: it started at the scheduled reboot, and once the pool ran low it began hitting machines during the week too.
For non-persistent instances both halves need to be scripted, activation at logon and deactivation at logoff. Both binaries sit in the Start10 program folder, and for Start10 the product ID is 2623.
Activate: SASUpgrade.exe -prodId=2623 -prodName="Start10" -company="Stardock" -ver="YOUR_VERSION" -email="YOUR_LICENSING_ADDRESS" serial="YOUR_KEY"
Deactivate: SdDisplay.exe -deactivate -prodID=2623 -prodName="Start10" -company="Stardock" -prodVer="YOUR_VERSION"
The company value is literally Stardock. Putting your own company name there is the most common reason a scripted activation fails.
Two things worth checking alongside that. Activation should not be baked into the golden image, because the license.sig it writes to \ProgramData\Stardock\Start10 is overwritten when the image deploys. That same file is how you confirm a given machine is genuinely activated.
The seats already burned by destroyed instances will need releasing from your account page, otherwise the logon script has nothing left to draw against.