feat(cutover): Faza C feature-flag infra for api.gis.ac

Server-side helper useGisAcFlag(email) → boolean, gated by:
- USE_GIS_AC=1 (global rollout switch), OR
- GIS_AC_PILOT_USERS=a@x,b@y (per-email staged rollout)

Both defaults are off (USE_GIS_AC=0, pilot list empty) in Infisical
/architools — this PR is dormant; no call sites consume the flag yet.
Future Faza D/E call sites in src/lib/gis-api-client.ts and
src/modules/geoportal/* will branch on it.

Exposed on session.useGisAc so client components can branch identically
to server routes without a separate API roundtrip. Re-evaluated per
request → flag flip via Infisical + container restart, no rebuild.

Per-user override (PILOT_USERS) is the rollout vehicle:
1. Deploy with flag=0 (default) → nothing changes
2. Set GIS_AC_PILOT_USERS=marius@... → Marius sees new code path
3. Watch 24-48h → set USE_GIS_AC=1 → global cutover
4. Rollback = unset USE_GIS_AC

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/core/feature-flags/use-gis-ac.ts

@@ -0,0 +1,20 @@
+// Server-side feature flag for the api.gis.ac cutover (Plan 003, Faza C).
+//
+// Off by default → all parcel/eterra/geoportal call sites keep using the
+// legacy local-DB code path. Flip via Infisical /architools:
+//   USE_GIS_AC=1                    → global enable
+//   GIS_AC_PILOT_USERS=a@x,b@y      → per-email override for staged rollout
+//
+// After redeploy, call sites read useGisAcFlag(session.user.email) and
+// branch between the legacy path and the gis-api thin client (Faza D).
+
+const PILOT_USERS = (process.env.GIS_AC_PILOT_USERS || "")
+  .split(",")
+  .map((s) => s.trim().toLowerCase())
+  .filter(Boolean);
+
+export function useGisAcFlag(userEmail?: string | null): boolean {
+  if (process.env.USE_GIS_AC === "1") return true;
+  if (!userEmail) return false;
+  return PILOT_USERS.includes(userEmail.toLowerCase());
+}