早餐店老板个体户：盈亏平衡与「多请一人」代价测算小工具——每天卖多少才回本，请一个帮工折成多少杯豆浆

请做一个单文件 HTML 的早餐店盈亏平衡测算工具，给个体户老板用——
把「每月到底要卖多少才不亏」和「每笔决定折成豆浆是多少杯」算清楚。

输入（页面手填，全部来自老板自己的账，工具不预置任何数字）：
- 固定成本（按月）：房租、水电燃气、现有人员工资合计、平台费
- 营业天数：每月实际开门的天数
- 品类表（每行）：品名 / 售价 / 单个成本（面、馅、蛋、豆、杯袋按
  实际耗用折算）。允许填「估」，但填了「估」的结果输出要带角标
- 选中一个「锚定品类」——店里最能代表营业额的那个（如包子或豆浆）

计算与输出：
- 每日盈亏平衡线：月固定成本 ÷ 营业天数 ÷ 锚定品类单位毛利 =
  「每天要卖多少个锚定品类才回本」；同时给组合口径：按现有品类
  销量比例折成「多少笼包子 + 多少杯豆浆」的一屏说法
- 三个翻译器（工具的核心，每条一行大字）：
  a. 多请一人：拟增岗位月薪 ÷ 30 ÷ 锚定品类单位毛利 = 每天多卖
     多少个锚定品类才养得起这个人
  b. 涨价模拟：某品类售价 +【Δ】元后，等于每天可以少卖多少个
     仍维持原利润
  c. 报废翻译：当日倒掉某品的成本 ÷ 锚定品类单位毛利 = 这屉等于
     白卖了多少杯
- 敏感度排序：房租 / 水电 / 人工 / 单个成本各 +10%，分别重算
  平衡线，按影响从大到小排——告诉老板四个旋钮里拧哪个最疼

实现要求：
- 单文件，无外部依赖、无网络请求；localStorage 存数据，刷新不丢
- 所有计算过程在页面上可见（公式 + 代入的数），不许只给黑盒结果
- 打印友好，一页 A4 放得下
- 不做登录、不做云同步

给编码代理的补充说明：
- 「估」的标记要贯穿到最终输出：凡参与计算的输入有一个是估的，
  平衡线结果旁就挂一个「含估算输入」的角标，点开列出哪几项是估的
- 单个成本字段的占位提示写清口径：「按实际耗用折算——一屉包子
  的面粉馅料成本除以个数，不是进货单价」
- 敏感度排序不许用百分比之外的形式呈现「影响」，不要画趋势图

为什么这样写

个体户不是不会算账，是算不到决策粒度。「月租三千、每天流水两千、好像还行」是他真实的思考方式，问题出在请人这种决定上：三千月薪感觉是个小数，换算成「每天多卖八十杯豆浆」立刻变得具体——够不够养一个人，早上六点半的柜台前自己就有答案了。三个翻译器全部往「锚定品类个数」上折，就是为了让每个决定都落在同一个具象单位上，老板对着蒸笼就能心算验证，工具说错了他看得出来。

「计算过程在页面上可见」是给个体户的工具区别给公司工具的地方。黑盒结果在这里没人信——老板会用自己脑子里的大数对一下，对不上就整个不用了。把公式和代入数字摊开，他第一次能看见平衡线是怎么来的，哪怕算错了也能指出错在哪。同理，「估」的角标设计是诚实出口：单个成本没人能填准，硬要求精确他会随便填个数，之后所有结果都建立在假数据上且没人记得是假的；允许估但强制标注，至少看的人知道哪里虚。

敏感度排序放最后是刻意的克制。盈亏平衡工具最常见的滥用是拿它做长期规划——「照这个平衡线我明年能攒出二店首付」——这类推算全部是编的，工具用「四旋钮各 +10% 谁最疼」把使用场景锁死在当下结构比较上，不往外推任何一步。

变量