feat: 优化签名热力图与金额展示

docs/first-version-development-requirements.md

@@ -559,7 +559,7 @@
 
 - 在“数据详单”之后增加“报表对账”一级菜单，包含“对账单”和“利润报表”两个二级菜单；页面必须读取真实 NestJS API 与 PostgreSQL 报表表，不得在前端按明细临时拼接或使用静态数据。
 - 对账单按发送日期、企业、企业应用汇总日发送条数和成功条数。发送条数、成功条数均按短信计费条数 `billingUnits` 统计，成功以最终 `delivered` 状态为准。
-- 利润报表按发送日期汇总日发送条数、成功条数、消费金额、成本金额、利润和利润率，支持在“企业应用”和“通道”两个统计维度间切换。
+- 利润报表按发送日期汇总日发送条数、成功条数、收入、成本金额、利润和利润率，支持在“企业应用”和“通道”两个统计维度间切换。收入必须逐条按“最终成功计费条数 × 该短信发送时的客户单价快照”计算后汇总，不能按当前应用单价倒算；退款状态不改变该成功收入口径。通道维度只将收入归属到短信最终提交所在通道，补发链路不得重复计算收入。利润报表页面、筛选结果汇总和 CSV 不展示返还数据。
 - 企业应用维度的消费金额只统计仍为 `charged` 的客户账单，最终失败并退款的短信不再形成收入；成本金额按每次真实提交的通道成本单价快照乘以该次提交最终成功的短信分片数计算。补发只有产生成功分片时才增加对应通道成本，失败、未知或尚未收到成功回执的分片不计成本。
 - 通道维度按实际上游 `accepted` 提交统计发送量，按分片回执统计成功量和成本；客户收入只归属最终有效提交，避免补发时重复计算收入。通道成本单价必须在提交记录创建时快照，后续修改通道单价不得改写历史成本；历史缺少分片审计但存在明确成功回执时，才按该次短信计费分片数兼容计算。
 - 利润等于消费金额减成本金额；利润率等于利润除以消费金额，消费金额为 0 时利润率按 0 展示。所有金额使用 `0.0001 元`整数金额单位持久化并按四位小数展示。
@@ -570,6 +570,7 @@
 - 平均到达时长只使用成功且时间有效的短信，按 `deliveredAt - submittedAt` 计算；每个日期、每个维度组先计算 P95，剔除大于 P95 的最慢 5% 样本后再求平均。无成功或无有效时间样本时展示为空，不以 0 冒充。
 - `SmsMessageRecord` 必须固化实际使用的 `drainageInfoId`。新短信在同签名已审核通过的引流信息中按正文精确包含 URL 匹配，优先最长 URL；最长 URL 出现多个同长度候选时视为歧义并不关联。历史短信使用同一规则回填，未命中或歧义统一归入“未关联引流信息”，不得把一条短信复制到签名下所有引流信息造成重复统计。
 - 发送质量报表与对账、利润报表共用 T+1 及 T-4 至 T-1 滚动重算任务，每次重算在同一日期事务内重建四个质量维度。
+- 签名活跃度热力图每天均记录已报备维度的单日真实提交尝试、上游受理业务短信和最终成功业务短信；报备通过后尚未满足完整观察窗口时状态为“观察中”，仍生成热力图快照但不产生预警消息或 Webhook。热力图每行展示 T-1 至 T-30 的上游受理业务短信合计，并按合计从大到小排序；观察窗口只控制是否预警，不得隐藏真实发送数据。
 - 对账单、利润报表、发送质量报表均提供导出功能。导出必须由真实 API 按页面当前筛选条件查询完整结果并生成 CSV，不得只导出当前分页或在浏览器内拼接静态数据。
 - 报备字段库采用自适应卡片布局，分开展示统计概览、签名/引流信息通用字段和字段定义；卡片明确展示通道引用数及通用配置数，已被引用的字段不可删除。
 - 运营端和客户端用户管理页的新增用户按钮使用标准小尺寸操作按钮，不得占用大块页面空间。
@@ -1558,11 +1559,12 @@
 
 ## 2026-07-16 全平台金额精度要求
 
-1. 企业应用客户单价、通道成本单价、账户余额、授信额度、充值、消费、返还、短信计费金额以及对账和利润报表中的全部金额，统一精确到人民币小数点后 4 位；输入最多允许 4 位小数，页面及导出文件统一展示 4 位小数。
+1. 企业应用客户单价、通道成本单价、账户余额、授信额度、充值、消费、返还、短信计费金额以及对账和利润报表中的全部金额，统一精确到人民币小数点后 4 位；输入最多允许 4 位小数，页面及导出文件统一展示 4 位小数。利润报表中的收入同样固定展示 4 位小数。
 2. 数据库和计费链路继续使用整数运算，最小金额单位统一为 `0.0001 元`，即 `1 元 = 10000 金额单位`。历史字段名中的 `Cents` 为兼容既有 API 暂不改名，但其数值语义同步调整为金额单位，不再表示人民币“分”。
 3. PostgreSQL 金额列统一升级为 `BIGINT`。上线迁移时既有按分保存的数据乘以 100，应用换算除数由 100 改为 10000，确保迁移前后实际人民币金额完全一致。
 4. 企业应用单价修改必须写入真实 `SmsApplication.customerUnitPrice`，例如 `0.0325 元/条` 保存为 `325`；后续预估、冻结、扣费、返还和利润统计均使用该整数值，不得在前端或后端再次四舍五入到分。
 5. API 返回 `BIGINT` 金额时仅在 JavaScript 安全整数范围内转换为 JSON number；超过安全整数范围必须显式报错，避免静默丢失金额精度。
+6. 所有运营端和客户端的只读金额文本，整数部分保持当前文字颜色，小数点及小数部分使用更淡的次级文字颜色；金额输入框和 CSV 等纯文本载体保持原始数值格式，不拆分字符。
 
 ## 2026-07-16 企业应用接口参数复制与下游接入约束
 
@@ -1959,7 +1961,7 @@
 ## 报表筛选结果全量汇总（2026-08-09）
 
 - 对账单、利润报表和发送质量报表在每次搜索后都必须展示当前筛选条件匹配的全部结果汇总，不得只对当前分页明细在前端求和。汇总、总数、分页和CSV导出必须复用同一套日期、企业、应用、通道及统计维度筛选口径。
-- 三类报表均汇总提交、发送、未知、成功和失败条数；利润报表另汇总净消费、返还、成本和利润金额。综合成功率必须按合计成功量/合计发送量重算，综合利润率必须按合计利润/合计净消费重算，不得对每行百分比求和或简单平均；分母为0时显示0%。
+- 三类报表均汇总提交、发送、未知、成功和失败条数；利润报表另汇总收入、成本和利润金额，不展示返还明细或返还合计。综合成功率必须按合计成功量/合计发送量重算，综合利润率必须按合计利润/合计收入重算，不得对每行百分比求和或简单平均；分母为0时显示0%。
 - 平均到达时长不属于可加总数据，本汇总区不对各日、各维度均值再求和；明细表仍保留每组的真实P95截尾平均到达时长。
 
 ## 新建企业省份与地市字典（2026-08-09）