Write a README a new contributor could follow without pinging you on day one

Write a developer README for this repository, using #codebase so you're describing the actual project structure and scripts as they exist right now, aimed specifically at someone who has never touched this codebase before and has no one sitting next to them to ask.

WHAT THIS PROJECT IS
An internal Next.js app that lets support reps look up a customer's subscription history and issue refunds without going through the billing team directly.

SETUP STEPS AS THEY CURRENTLY WORK
Clone the repo, copy .env.example to .env and fill in the DATABASE_URL from the team vault, run `pnpm install`, then `pnpm db:migrate` before `pnpm dev` — migrate has to run first or the dev server crashes on boot.

GOTCHAS THAT HAVE TRIPPED PEOPLE UP BEFORE
If you skip pnpm db:migrate, the dev server throws 'relation \"subscriptions\" does not exist' on the first request, which looks like a connection problem but isn't.

A GOOD FIRST TASK TO POINT SOMEONE AT
The `formatRefundAmount()` util in lib/currency.ts has a known rounding edge case on JPY amounts (no decimal places) tracked in issue #142 — small, contained, and touches a real part of the codebase.

Write the setup section as steps that were actually verified to work, in order, including any step that feels obvious to someone who already has the repo working — the failure mode this README exists to prevent is a step that got skipped in the writing because it felt too basic to mention, and that's precisely the step a first-timer trips on. For each gotcha listed, don't just state the gotcha — state what it looks like when it goes wrong (the actual error message or symptom) so a new contributor can pattern-match their own screen against this document instead of wondering if they're even hitting the documented issue. Read the actual package.json / equivalent scripts file via #codebase and list the real script names and what each one actually does, not a guessed-at convention like 'probably npm run dev' — if a script's actual behavior doesn't match what its name suggests, note that explicitly.

Do not pad this with sections that don't apply to a first-time contributor's first day — skip a detailed architecture deep-dive or a full contribution-guidelines legal section unless it's directly relevant to getting a working local environment and understanding where to start; those belong in a separate document this README can link to, not inline in the first thing a new contributor reads.

OUTPUT FORMAT
1. One-paragraph project description.
2. Setup steps, numbered, verified against actual scripts.
3. Common gotchas, each with symptom + fix.
4. Suggested first task with a one-line reason it's a good starting point.
5. Links to anything this README deliberately left out (deeper architecture docs, contribution guidelines) rather than covering them here.