Nice progress — with compute ACTIVE and the app RUNNING, we've eliminated the original cause and narrowed this down to the auth/access layer. A few thoughts:

First, one thing in your test that's easy to over-read: the Python requests behavior is actually *expected*, not evidence of a broken flow. requests has no browser session — no workspace cookies, no identity — so 302 → login page is exactly what should happen for an unauthenticated client. That test can't distinguish a healthy app from a broken one. The signal that matters is what happens in a browser where you're already logged into the workspace.

Second — and I'd test this before anything else, because it's cheap: the current Free Edition limitations page (updated July 20, 2026) says **one Databricks App per account**, and you now have at least two (the original mail-agent-ui-v2 plus the new mail-agent-test). You mentioned docs saying 3 — that may be the limit for LinkedIn-verified accounts, since verification raises some Free Edition limits, but the base limit documented today is one. Try deleting the old app so exactly one exists, restart the remaining one, and test the URL again. If the platform enforces the one-app limit somewhere in the serving/auth layer, that alone could explain an app that reports RUNNING but never becomes reachable.

If that doesn't fix it, the key question for diagnosis: in your logged-in browser, when you open the app URL in a new tab, what's the exact sequence? Two very different failure modes:

(a) You get bounced to login, authenticate successfully, and *then* land on "App Not Available" — that smells like an authorization/provisioning problem (your hypothesis).

(b) You see "App Not Available" immediately without completing a login round-trip — that's more like the OAuth handshake between the two domains failing.

If it's (b): the app lives on *.databricksapps.com while auth happens on *.cloud.databricks.com — a cross-site flow. Browser privacy features (third-party cookie blocking, tracking prevention, extensions) can break exactly this kind of handshake. I know you tested multiple browsers, but one run in a clean incognito window with shields down, logging in fresh, rules it out cheaply. Also try opening the app via the Open button on the app's page in the workspace UI (Compute > Apps) rather than pasting the URL — same destination, but it guarantees you arrive from an authenticated session.

On your actual question — a Free Edition-specific OAuth restriction for Apps — I can't confirm or deny it from public docs, and I found no other reports of this exact symptom this month. What I *can* say is that tier-based OAuth provisioning restrictions demonstrably exist on Free Edition: in a recent thread, a Databricks architect confirmed the Genie mobile OAuth app simply isn't provisioned for Free Edition accounts, and login fails at exactly that layer. Different OAuth client, but the same category of restriction — so your hypothesis isn't far-fetched. That said, Apps are officially supported on Free Edition (within the limits above), so browser access breaking by design would be strange.