Linux Consumption Function App stuck with 0 running workers for 24+ hours - reproduces across regions, plans, storage accounts, and runtimes

I'm trying to get a brand-new Linux Consumption (Y1) Function App running and it never successfully starts — Azure's own built-in diagnostics confirm 0 running workers for over 24 hours straight, and this reproduces no matter what I change.

• The app's SCM/Kudu site (https://<app>.scm.azurewebsites.net) returns a blank "The service is unavailable" page — confirmed both in a browser and via API calls, so it's not a client-side issue.
• The Portal's own Overview page shows "Runtime version: Error" instead of an actual version.
• The Functions list in the Portal shows "We were not able to load some functions in the list due to errors."
• Using the Portal's "Diagnose and solve problems" > "Function App Down or Reporting Errors" report, the "Functions that are not triggering" check shows: "Function was running on 0 worker instance for more than 1420 minutes" (over 23 hours) — all other checks (Python Function, Key Vault settings, deployment settings, etc.) pass cleanly.
• Application Insights (linked correctly) shows zero telemetry of any kind for this app — not just no errors, no requests/traces/exceptions at all — across the whole window, meaning the host never gets far enough to log anything.

Not the issue - Since this reproduced identically every time, I've tried recreating the app under every combination below, in case one specific resource was corrupted or stuck:

• Deleted and recreated the Function App itself (same name), 4 times.
• Deleted and recreated the underlying Consumption hosting plan too, not just the app.
• Two different regions (South Africa North, then North Europe).
• Two different, completely fresh storage accounts for AzureWebJobsStorage.
• A completely different language runtime (a throwaway Node.js 24 app) — identical symptom, ruling out anything Python-specific.
• Restarted via the Portal/CLI — no change.
• Waited 15+ minutes between checks multiple times, to rule out a slow cold start.

Every single combination shows the exact same "0 workers" behaviour. Since it's independent of region, plan, storage account, and runtime, I don't think it's anything in my own configuration — it looks like the Consumption plan's scale controller simply never allocates a worker for this app/subscription.

Has anyone seen this exact "0 running workers, indefinitely" pattern before, and is there a known fix or a next diagnostic step I'm missing? Happy to share more detail (correlation IDs, resource names, etc.) if it helps.

Thank you in advance!