fix(orders): provide rate limit configuration and loopback bypass for order writes #1073

Bug Description

In main/routes/orders.ts:73-87, orderWriteRateLimit and orderItemCancelRateLimit hardcode an in-memory limit of 60 requests per minute (windowMs: 60 * 1000, limit: 60). During peak rush hours or automated E2E test runs, burst traffic exceeding 1 req/sec causes immediate HTTP 429 rejections, blocking order creation and item cancellations with no environment variable hook or loopback exemption.

Invariant / Contract Violated

Core Invariant: Offline-First Operation - Local POS operations must remain responsive under heavy store rush without hard rate-limiting blocks on local IPC/loopback.

Steps to Reproduce

1. Send 61 consecutive POST /api/orders order creation requests within a 60-second window.
2. Observe the response to request UI: Merge General tab save buttons into one sticky footer #61.

Expected Behavior

Requests succeed or rate limits adapt based on environment configuration (FLO_ORDER_WRITE_RATE_LIMIT_MAX) or bypass local loopback.

Actual Behavior

HTTP 429 Too Many Requests with payload {"error":"Too many order requests. Try again later."}.

Minimal Reproduction Code

test('reproduce order write rate limit burst', async ({ request }) => {
  const serverToken = getE2eToken('e2e-server', '[email protected]', 'server');
  for (let i = 0; i < 61; i++) {
    const res = await request.post('/api/orders', {
      headers: { Authorization: `Bearer ${serverToken}` },
      data: { type: 'dine_in', items: [{ product_id: 'e2e-product', quantity: 1, unit_price: 100 }] },
    });
    if (i === 60) {
      expect(res.status()).toBe(201); // Fails with 429
    }
  }
});

Sanitized Logs / Error Output

HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
{"error":"Too many order requests. Try again later."}

Environment

• Version/Commit: 3.12.88-beta (8277362)
• Actor Role: cashier, server
• Viewport: 1920x1080

Scope Boundary & Non-Goals

• In Scope: Support FLO_ORDER_WRITE_RATE_LIMIT_MAX or skip rate limiting on loopback/test environments in main/routes/orders.ts.
• Non-Goals: Do not remove rate limiting on public external interfaces or alter order validation transactions.

Acceptance Criteria:

• The minimal reproduction test passes.
• No regression in adjacent tests (npm run test:e2e:browser).
• Follows existing backend/frontend architecture invariants.

Suspected Root Cause

main/routes/orders.ts#L73-L87 (Hardcoded in-memory expressRateLimit without env overrides or test bypass) (Analysis only; no fix applied in this audit)