estimatedCostUsd is capped at $100M, which is below cases already in the registry

[royalpinto007]

lib/schemas/submit.ts caps the damage figure at 100 million USD:

estimatedCostUsd: z.number().int().min(0).max(100_000_000).optional(),

The registry already contains a case above that ceiling. APM-0061 (Zillow shutting down its algorithmic home-buying business) records estimated_cost_usd = 540000000, sourced directly from the cited reporting. There is at least one more case, APM-0057 (Alphabet losing roughly 100 billion dollars of market value after the Bard demo), where the narrative states a figure that cannot be represented at all, so the field is left null and the registry loses the single most useful number in the case.

Consequences today:

• The submit form (components/post/SubmitForm.tsx) rejects any honest submission of a nine-figure-plus incident, which is exactly the class of incident this registry exists to record.
• app/api/posts/edit/[token]/route.ts validates against the same schema, so the submitter of APM-0061 cannot edit their own case: any edit re-submits the existing cost and fails validation. The record is effectively frozen.

Worth deciding as part of this:

• What is the real ceiling? Some documented AI incidents run into the tens of billions, so the bound should be chosen deliberately rather than left at a round 100 million.
• Does the column type in Postgres hold it? Confirm estimated_cost_usd is bigint and not integer, since integer tops out at 2,147,483,647 and would silently block anything above that regardless of what Zod allows.
• Keep .int() and .min(0). The point is the upper bound, not the shape.

Please include a test in a schema test file covering the boundary and one over it, and check types/supabase.ts stays accurate.

If you would like to take this on, comment here to claim it. Contributors can hold two open claims at a time.