Fix workflow shares causing crash

From the PR description

getAdminClient() was reading NEXT_PUBLIC_SUPABASE_URL - that's a Next.js frontend convention that the backend never had defined. The empty fallback made supabase-js throw "supabaseUrl is required" synchronously from inside the GET /workflows handler the moment a user had at least one workflow_shares row (the only code path that calls admin.auth.admin.listUsers). The unhandled rejection crashed the ECS task, hit the Fargate restart loop, and the frontend got a 500 it swallowed with .catch(() => setCustom([])) - so the user saw an empty workflow list with no obvious clue why.

The right env var on the backend is SUPABASE_URL (matches lib/supabase.ts). This is a pre-existing latent bug, not a Phase 2 regression - it just hadn't fired before because nobody had ever been a workflow share recipient until the Phase 2 cutover was tested end-to-end and the encryption side correctly stored the share rows.

The diagnostic chain was instructive: encrypted columns and HMAC index round-tripped fine; the backend simulation said shares should appear in /workflows responses; but CloudWatch /ecs/mike-backend showed three task restarts with the same trace pointing at workflows.js:11 - exactly the call site that reads the missing env var. The fix is one character of identifier rename plus the explanatory comment above the call.