Add Restocking tab and system architecture doc

[farhanbhagat99]

Adds a budget-driven restocking workflow: a new Restocking tab lets users set an available budget, see items recommended from demand forecasts (prioritized by urgency and rising demand), and submit an order that appears in the Orders tab under a new "Submitted Orders" section with delivery lead time. Backfills unit_cost onto demand_forecasts.json since its SKUs don't overlap inventory.json's, so recommendations couldn't otherwise be costed.

Also adds docs/architecture.html, a static overview of the system's tech stack, architecture, and data flow for onboarding.

[farhanbhagat99]

Reviewed this with a fresh pair of eyes (independent pass, not just re-reading what I wrote). Overall the backend is solid and convention-compliant, but there's one real bug in the frontend interaction that undermines the feature's core UX, plus a few things worth tightening before merge.

🔴 Bug — checked-item selection resets on every budget change

client/src/views/Restocking.vue — applyRecommendations():

const applyRecommendations = (data) => {
  recommendedItems.value = data.recommended_items
  totalCost.value = data.total_cost
  checkedSkus.value = new Set(data.recommended_items.map(item => item.sku)) // always re-checks everything
}

This runs from both loadInitial() and every debounced onBudgetInput() fetch. So: uncheck an item, then nudge the slider by even 1px, and the exclusion is silently wiped — everything gets re-checked. That breaks the "uncheck items to exclude them from the order" interaction the UI advertises.

Fix: only seed "all checked" on the very first load; on subsequent budget-driven refetches, preserve existing unchecked state for SKUs that are still present, e.g.:

const applyRecommendations = (data, isInitial = false) => {
  recommendedItems.value = data.recommended_items
  totalCost.value = data.total_cost
  const newSkus = new Set(data.recommended_items.map(i => i.sku))
  checkedSkus.value = isInitial
    ? newSkus
    : new Set([...checkedSkus.value].filter(s => newSkus.has(s)))
}

🟡 Recommended before merge

• No server-side validation on restocking order items (server/main.py — RestockingOrderItem): quantity/unit_price are trusted from the client with no bounds. Low blast radius here (in-memory demo, resets on restart), but cheap to fix with Field(gt=0) constraints per this repo's own documented Pydantic convention.
• Float comparison in the budget cutoff (compute_restocking_recommendations): running_total + candidate['line_total'] <= budget compares raw floats with no epsilon, so hitting exactly budget_max can drop the last item by a sub-cent rounding error. test_full_budget_covers_every_candidate uses a < 0.01 tolerance specifically to paper over this — worth a small epsilon in the actual comparison instead.
• Submitted orders use real wall-clock dates while the rest of the mock dataset (and QUARTER_MAP) is anchored to 2025, and new orders get warehouse: None, category: None. Any active Time Period/Warehouse/Category filter will make the "Submitted Orders" section disappear after placing an order — probably fine for a demo, but worth a quick gut-check since it's an easy "wait, where did my order go?" moment.

🟢 Nice-to-haves

• Restocking.vue renders {{ item.name }} directly instead of via translateProductName() like Orders.vue — inconsistent with the app's i18n convention (currently invisible since these item names aren't in the ja translation map).
• docs/architecture.html doesn't mention the new Restocking view/endpoints — reasonable to bundle a docs update with a feature PR, but it's stale on day one as written.
• Test gaps in tests/backend/test_restocking.py: no negative/zero budget or quantity/unit_price cases, and nothing directly asserting the "increasing-trend-first" priority ordering.

What's good

• Backend models/endpoints follow existing FastAPI/Pydantic patterns cleanly.
• Both locale files updated together, good coverage for the new strings.
• v-for keys use stable IDs (item.sku, order.id) throughout — no index-as-key regressions.
• Tests assert real monotonic behavior (test_increasing_budget_never_decreases_recommendations), not just 200-smoke-tests.

Happy to push a follow-up commit for the checkbox-reset fix + the Pydantic constraints if useful — those are the two I'd actually block on.

[farhanbhagat99]

Pushed fixes for both blocking items from the review above:

• 6d83e89 — fixes the checkbox-reset bug (unchecking an item now survives subsequent budget-slider changes; only the very first load defaults everything to checked) and adds Pydantic validation (quantity > 0, unit_price >= 0, item list capped at 100) to POST /api/restocking/orders. Added corresponding tests.
• 9796008 — unrelated pre-existing Reports page bugs found and fixed in a separate pass (no i18n, ignored the global filter bar, console spam, Options-API/index-key/O(n²) inconsistencies vs. the rest of the app). Bundled into this branch since it was already open; happy to split into its own PR if preferred.

All 62 backend tests pass, production build is clean, and both fixes were verified live in the browser (checkbox exclusion persists across slider moves; Reports page now translates, filters, and is silent in the console).