Push Copilot's /tests beyond the happy path with edge cases it won't reach for on its own

Generate unit tests for the function below using Vitest, with describe/it blocks and the existing project's custom `renderCart()` test helper, matching the conventions of the existing test file so this reads like it was written by the same person, not a separate generated block bolted on afterward.

FUNCTION UNDER TEST
applyDiscountCode(cart, code) in checkout/discounts.ts

EXISTING TEST FILE FOR STYLE REFERENCE
checkout/discounts.test.ts

EDGE CASES THAT MUST BE COVERED
Discount code applied twice in one session, code that's valid but the cart total is below the minimum spend, and a code that expired exactly at the current timestamp (boundary, not just past-expiry).

WHAT TO MOCK VS. WHAT TO LEAVE REAL
Mock the external pricing API call, but let the actual discount-calculation math run for real — don't mock the function under test's own internal logic.

WHAT NOT TO DO
Do not stop at one happy-path test and call the suite done — a single passing-input test is the case Copilot generates by default with no further instruction, and it is also the least useful one, since it's the case most likely to have already been checked manually before the code shipped. Do not mock something the mocking boundary above says should stay real, even if mocking it would make the test simpler to write — a test that mocks around the exact thing it should be verifying gives false confidence, not real coverage. Do not invent an edge case that isn't listed above and isn't a case any reasonable reading of the function would surface (like null input or an empty array) — pad the suite with cases that matter, not with cases that exist only to inflate the count. Do not rename or restructure existing tests in the reference file; only add new ones in the same style.

For each edge case listed above, write one test that isolates it — don't fold two edge cases into a single test where a failure would be ambiguous about which condition actually broke. If a listed edge case turns out to be already covered by an existing test in the reference file, say so explicitly instead of duplicating it.

OUTPUT FORMAT
1. New test cases, in the same file and style as the existing reference file.
2. A one-line note for any listed edge case that was already covered and therefore skipped.
3. A short list of any edge case you'd recommend adding beyond what was listed, with a one-sentence reason each — as suggestions only, not added to the file unless I ask.