feat(ops): warn when the tier outgrows the rate limiter's single-instance assumption

[bgard68]

The assumption

Throttling counters live in the serving process's memory. That is correct on F1, which runs one instance — one counter table, and it is the whole picture.

It stops being correct the moment a second instance exists. Each keeps its own counters and enforces the configured budget separately, so two instances allow twice the configured limit and four allow four times.

Nothing about that surfaces on its own. No error, no rejected request, no log line — the numbers in appsettings.json simply stop being the numbers in effect. Same silent-failure shape as the proxy misconfiguration ProxyConfigurationCheck already exists for, and it deserves the same treatment: a check, not a comment.

The sharp edge this guards

Provision.ps1:42 takes the tier as a parameter, defaulting to F1. Passing -Sku S1 is a one-word change that silently multiplies every limit by the instance count.

What it does

ScaleOutCheck warns once at startup when WEBSITE_SKU names a tier that can run more than one instance — anything other than Free or Shared.

Two deliberate choices, both pinned by tests:

• It reports capability, not live instance count. No instance can see how many siblings it has, so "this deployment can scale out" is the only available signal — and the more useful one anyway, since on an autoscaling plan the second instance arrives with nothing marking the transition.
• An unrecognised tier warns rather than staying quiet. A tier this code has never heard of is likelier to be new and scalable than new and single-instance, and the wrong guess in that direction is the silent one.

Absent off App Service — local runs, containers — where there is no platform claim to check, so it stays quiet rather than training an operator to ignore it.

Testable by construction

It takes the SKU as an argument instead of reading the environment itself. That is the direct lesson from the defect fixed earlier on this branch: logic that reads its own inputs is logic a test cannot drive, and unreachable code is exactly how the forwarded-header bug survived review, CI, and coverage.

Documentation

The config handbook now states the constraint outright, including why the database is not a substitute for a shared counter store: counters are written on every request, rejected ones included, so a serverless database would be billed for compute in proportion to the abuse the limiter exists to absorb.

Verification

• 16 new tests covering single-instance tiers, scale-capable tiers, casing, absent values, unknown tiers, and log-forging via a hostile WEBSITE_SKU.
• 546 tests pass against real PostgreSQL.
• dotnet format --verify-no-changes clean, 0 warnings under -warnaserror.

---

Generated by Claude Code