A StoreKit configuration file only verifies the local product configuration, so I would next test with the scheme's StoreKit Configuration set to None on a physical device/TestFlight build and log the exact identifiers returned by Product.products(for:). Also verify pricing/availability, Paid Apps agreement, and that the first subscription/IAP products are attached to the submitted app version. If the products remain selectively absent, collect a sysdiagnose and file Feedback Assistant because it may be catalog provisioning. I offer a focused 24-hour StoreKit/App Store Connect diagnostic if you want someone to review the configuration and logs and separate developer-controlled issues from Apple-side failures.

The timing, locked metadata, and resolved App Store Connect incident suggest this may be an Apple-side review-state problem rather than an app defect. I would avoid deleting or recreating the subscriptions until Apple confirms their state. Capture the subscription IDs, status timestamps, incident window, and current App Store Connect screens in a Feedback Assistant report and reference your existing support cases. I provide focused App Store/StoreKit diagnostics; if you want, I can review the evidence and determine whether anything remains developer-controlled before you spend money on implementation.

the question is irrelevant since after production there are no ways to create a new recordtype programmatically.

I am Seeing this without knowing what is the cause

Everything back to normal