feat(frontend): give order history a page of its own (#121)

The account modal had accumulated: a profile line, a name form, two collapsed panels for changing email and password, two consent switches, an order table and four controls. The table was the piece that fitted worst, being the only tabular data in a 700px dialog whose body is capped at 70vh. The scroll={{ x: 'max-content' }} already on it was a workaround for being in the wrong container rather than a layout choice.

It moves to /orders, an ordinary page in the same Routes block as /cart and /privacy, rather than another entry in MODAL_ROUTES. Order history is a list you read, like the cart, not a dialog you dismiss. A modal at /account/orders would have been the smaller change and was rejected: it inherits the same width and the same scroll cap, so it moves the table without giving it anything.

The page shell follows Cart.tsx, which is the established shape here: a Layout with a Header carrying Back to Shop and the title, and the same guard sending a signed-out visitor to /login. The account modal keeps a View order history button where the table used to be, because that is where a customer looks for it.

One thing changes rather than moves. The old effect caught a failed load with a toast and left orders as an empty array. The toast faded and the empty table did not, so from then on a customer whose request failed saw exactly what a customer with no orders saw, and the page asserted something false. Loading, failed and empty are now three distinct states, and the failed one carries a Retry: a transient failure would otherwise strand someone on a page that needs a full reload to recover.

OrdersBody sits at module level rather than nested inside Orders(). A function declared inside a component counts toward that component's cognitive complexity, which is what made Customers() hard to bring back under the threshold in #81.

The two assertions in account-modal.spec.ts that looked for the text "Order History" inside the modal are updated to look for the link, not deleted. They were the only coverage that the account view still offers any route to the orders, which is exactly what this change could have silently broken.

Verification, against a real backend and database: five new tests covering the signed-out redirect, the empty state, Back to Shop, the link from My Account, and that the page renders as a page rather than a modal over the storefront - that last one is what would catch /orders being added to MODAL_ROUTES and quietly undoing the change. The full suite goes from 100 to 105 passing with no new failures; the three that fail did so before this branch and fail identically on main. tsc and the production build are clean, ESLint reports no errors.

Closes #121
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/tests/e2e/account-modal.spec.ts

@@ -95,7 +95,9 @@ test.describe('My Account opens as a modal', () => {
 
     const modal = accountModal(page);
     await expect(modal).toContainText(email);
-    await expect(modal).toContainText('Order History');
+    // The orders table lives at /orders now. What the account view still owes
+    // the customer is a way to reach it.
+    await expect(modal.getByRole('button', { name: 'View order history' })).toBeVisible();
     // Scoped to the modal: the storefront behind it has a theme switch of its
     // own, so an unscoped switch locator would be ambiguous.
     await expect(modal.getByRole('switch')).toHaveCount(2);
@@ -126,7 +128,7 @@ test.describe('My Account opens as a modal', () => {
     // The view is taller than the viewport, so the body scrolls rather than
     // pushing the title and close control off-screen.
     await expect(modal.getByRole('button', { name: 'Close' })).toBeInViewport();
-    await expect(modal.getByText('Order History')).toBeVisible();
+    await expect(modal.getByRole('button', { name: 'View order history' })).toBeVisible();
 
     await closeAccount(page);
     await expect(page).toHaveURL(/\/$/);