Org Web Adapter

Editing hungryroot/jira/be_7138_fix_ingredient_credits_type_mismatch_between_openapi_spec_and_endpoint_get_api_v3_pairings.org

:PROPERTIES:
:ID:       f88e91d3-8209-470d-9906-64563f968fd8
:END:
#+title: BE-7138 Fix ingredient_credits type mismatch between OpenAPI spec and endpoint GET /api/v3/pairings/

- source :: https://hungryroot.atlassian.net/browse/BE-7138
- tags   :: [[id:3a477c02-e26d-40f7-a719-0aa1cd169dd8][Hungryroot API Project]] 
- epic   :: [[id:86327fb4-0f66-4bc6-9068-c414cea77042][EP-411 Eng Parking Lot]]
- sprint :: [[id:30370b03-0b10-4105-87da-641cdda1bcb7][HR BE Sprint 104]]
- status :: [[id:ec92a960-cac1-4b05-b4f5-25a2935eea75][Status - To Do]]

* Description
https://github.com/hungryroot/web/pull/3381#discussion_r2801995769

The TypeScript client type for ingredient_credits on the pairings ingredients
expansion does not match the OpenAPI spec, creating a contract mismatch that
could surprise future consumers.

Problem

The OpenAPI spec for GET /api/v3/pairings/ defines ingredient_credits as:

Type: number

Format: double

Required: yes (when expand=ingredients is used)

However, the TypeScript client types this field as string? (optional string).

This is not a runtime issue today because the current usage in transforms.ts
wraps the value with Number(ingredient.ingredient_credits), which coerces both
strings and numbers correctly. But the mismatch means:

Future consumers reading the TypeScript types will assume the field is an
optional string, not a required number.

Code generation tools that rely on the TypeScript types (rather than the OpenAPI
spec) will propagate the incorrect type.

Type safety is weakened -- TypeScript won't catch cases where the value is used
directly without Number() coercion.

Expected Fix

Update the TypeScript type definition for ingredient_credits to match the
OpenAPI spec:

Change the type from string? (optional string) to number (required number)

Audit usages of ingredient_credits across the frontend codebase to confirm they
are compatible with the corrected type (the Number() wrapper in transforms.ts
would become a no-op but is harmless to leave)

Remove any unnecessary Number() coercions if desired, or leave them as defensive
coding

Acceptance Criteria

[ ] ingredient_credits TypeScript type matches the OpenAPI spec (number,
required)

[ ] All existing usages compile cleanly with the updated type

[ ] No runtime behavior changes (this should be a types-only fix)