Malatang next-day ordering and rehydration scheduler tool - a purchase order that comes with soaking alarms

You are a senior front-end engineer. Build me (the person who handles ordering at a
malatang shop) a single-file HTML tool - zero external dependencies, no build step,
double-click the .html to run, works in mobile browsers too. All computation happens
locally; no network requests of any kind.

Tool name: Next-Day Ordering & Soaking Scheduler

1. Data area (item library)
- One record per ingredient: name, category (leafy greens / frozen meatballs &
  goods / dried-soak / condiments / fresh meat), unit (jin / bag / kg), average
  daily sales, current stock, safety stock days
- Dried-soak items carry two extra fields: soak duration (hours) and earliest
  needed-by time (default one hour after tomorrow's open; editable)
- Full add / edit / delete; data persists in localStorage across opens

2. Purchase order generation (button-triggered)
- Formula: suggested order = max(0, average daily sales x safety days - current
  stock), rounded up to the "usual purchase unit" (per bag, per case)
- Weather / traffic correction: one manual multiplier input (default 1.0; down
  for rain, up for weekend) - the multiplier touches the suggested order only,
  never the stored average daily sales
- Output table sorted by stockout risk descending: risk = current stock / average
  daily sales (fewer days left ranks higher); ties broken by suggested quantity
  descending
- Generates a plain-text order (item, quantity, unit) with a "copy" button -
  paste it straight into WeChat for the supplier

3. Soaking schedule (same screen, generated together with the order)
- Lists dried-soak items only
- Per item: start-soaking time = earliest needed-by time - soak duration
- Two columns by start time: soak tonight (before close) and soak tomorrow
  morning, each in time order
- Hard validation: if start time + soak duration > earliest needed-by time
  (except items whose soak exceeds overnight duration - those auto-file under
  "tonight"), flag the row red with the message "soak won't finish in time -
  either start earlier tonight or switch to a shorter-soak substitute"

4. Acceptance tests (run all three before delivering)
1. Create "wood ear," soak 2 hours, needed-by tomorrow 10:00: the schedule must
   show a start time of 08:00, filed under tonight or tomorrow morning depending
   on where the device clock falls
2. Create "tofu sticks," soak 6 hours, needed-by tomorrow 10:00: if the current
   time is past 20:00, the row turns red with the too-late warning
3. Wipe localStorage and reload: the page shows an empty-state onboarding
   prompt, not an error

UI requirements: mostly one screen, two blocks side by side (stacked on mobile);
plain color scheme, generous font sizes - this runs in a kitchen, possibly with
gloves on and steam on the screen.

Constraints:
- No CDNs, fonts, or icon libraries - fully offline
- No user accounts, no cloud sync - localStorage is the only storage
- No pre-filled "industry average sales" data - every number is mine to enter
- No ingredient names hard-coded anywhere - everything comes from my item library

Why it is written this way

The hard part of malatang ordering isn't "how much" but "how early": rehydration turns an ordering problem into a scheduling problem. Most ordering tools (including off-the-shelf inventory systems) output quantities only and leave soaking times to human memory - and human memory is at its worst during close-down. This tool's core value is freezing the subtraction "needed-by minus soak duration" into code that recomputes the start times every night and splits them into tonight / tomorrow columns matching the real work rhythm.

Stockout risk as the sort key (rather than value) follows the same logic as an early-warning tool: the item with the fewest days of cover gets ordered first, regardless of what it costs. The weather multiplier touching only the suggestion and never the stored baseline is an easy-to-miss but critical design - once a rainy-day demand dip pollutes the average-sales baseline, every sunny day after it over-orders forever.

The acceptance tests are three runnable cases rather than adjectives like "clean UI": wood ear at 2 hours and tofu sticks at 6 hours, one exercising the happy path, one the too-late interception. A coding agent handed concrete cases misses by an order of magnitude less than one handed a paragraph of requirements.

"No pre-filled industry data" and "no hard-coded item names" guard the two classic failure points of this kind of tool: pre-filled "industry averages" look helpful but are fabricated numbers that wreck the shop's first real order, and hard-coded names make the tool unusable at the very first shop that isn't yours. Big fonts, plain colors, one screen - because the actual usage scene is ten at night, under kitchen lights, possibly wearing gloves.

Variables