fix(fygaro): serve the v0.6.7 allowance query instead of 400ing it

[bobodread876]

Every card top-up amount screen on v0.6.7 shows an error toast reading "StatusCode: 400 / Error code: undefined". Reproduced against prod.

What v0.6.7 sends

query fygaroTopupAllowance {
  fygaroTopupAllowance { limit held remaining holdsExpireAt }
}

Those are fields of FygaroTopupAllowance. The query field returns FygaroTopupAllowancePayload (allowance, errors, unavailableReason), so the server answers 400 GRAPHQL_VALIDATION_FAILED — and the app's global Apollo handler turns any 4xx into a toast.

$ curl -s -o /dev/null -w '%{http_code}' api.flashapp.me/graphql -d @v067-query.json
400

How it shipped

Codegen ran against a checked-in schema that still described the pre-payload shape. flash-mobile's app/graphql/public-schema.graphql:1857 in the v0.6.7 tree still reads:

fygaroTopupAllowance: FygaroTopupAllowance

The generator validated happily against a schema the server had already moved past. Codegen is only as honest as the schema you check in — a CI check that the committed SDL matches the deployed one is the real fix for the class, and belongs in flash-mobile.

Why fix it server-side

Aliasing the four fields onto the payload fixes every already-installed v0.6.7 with no store release. Those users cannot be reached any other way, and v0.6.7 went public today. All four carry @deprecated and get deleted once that build ages out.

Why limit/held/remaining are NON-NULL

This is the subtle part, and it is the opposite of the instinct.

When the allowance is unavailable (ERPNext unreadable, rate limited, checkout disabled) they resolve to null, the non-null violation propagates to the root, and data goes null. That is exactly what the app already handles: data?.fygaroTopupAllowance is undefined, so it falls back to rendering the flat per-level cap — the same thing it does today when the query 400s.

Nullable would be worse. use-card-topup-allowance.ts builds its allowance object from any truthy payload, so nulls would produce {limitCents: null, remainingCents: null} and the screen would tell a customer they have nothing left to spend. A false refusal in place of a graceful fallback.

And the propagation produces a GraphQL error on a 200, not a network error — the app logs those and never toasts them ("only network error are managed globally", client.tsx). So the fallback is silent in exactly the case that needs it.

Severity

Always cosmetic: the allowance degraded to the flat cap and top-ups worked throughout — which is why signed checkout tested clean. But it put a raw status code in front of a customer on a money screen, every time.

Tests

test/flash/unit/graphql/public/types/object/fygaro-allowance-legacy-fields.spec.ts holds the v0.6.7 document as a frozen literal — copied from the shipped tag, not regenerated, because its whole value is being a copy of what a real build sends. Regenerating it from the current schema would make it agree with us by construction and assert nothing.

Four cases: it validates; it serves the values; an unavailable allowance nulls data rather than zeroing it; and the modern payload shape is undisturbed.

The schema is built around the real payload type rather than from SDL — buildSchema would give default resolvers that read payload.limit directly and pass whether or not the aliasing resolvers exist.

205 suites / 2219 tests green. tsc and eslint clean. SDL and supergraph regenerated via yarn write-sdl.