feat(cache): 建立字典缓存快照（T-103）

docs/03-目标架构设计.md

@@ -59,6 +59,7 @@ chis_osi/
 ├── contract/          ★ 校验后的接口契约（请求/响应结构体 + serviceId 常量）
 │   ├── envelope.go    通用信封：{serviceId, uploadinfo|baseInfo, manageInfo}
 │   └── jkda.go / jktj.go / lnr.go / ...
+├── cache/             公开字典缓存：网格/责任医生/机构 → 映射层主数据反查
 ├── mapping/           ★ PHIS→OSI 映射（本项目核心）
 │   ├── dict.go        码表：性别/民族/血型/职业/文化程度/婚姻/医保...（双向）
 │   ├── health_record.go  档案字段映射 + 校验
@@ -133,7 +134,11 @@ type UploadInfo struct {
 type ManageInfo struct { DSFMC, OperateUnit, OperateUser string }
 ```
 
-### 4.3 `mapping` —— PHIS→OSI 映射（核心）
+### 4.3 `cache` —— 公开字典缓存
+
+承接 `osi/public.go` 的网格、责任医生、机构查询结果，生成内存 `DictionarySnapshot`，按名称反查创建档案所需的 `regionCode`、`manaDoctorId`、`manaUnitId`。持久化存储通过可选接口接入，Redis 不可用时只影响持久化，不阻断内存快照刷新和映射。
+
+### 4.4 `mapping` —— PHIS→OSI 映射（核心）
 
 把旧项目"对齐 Chrome"的隐式逻辑，重写为"对齐文档"的显式逻辑：
 
@@ -145,14 +150,14 @@ type ManageInfo struct { DSFMC, OperateUnit, OperateUser string }
 > 完整度（completeLevel/perfection）：默认**不本地计算**，按文档字段如实上送，依赖平台计算。
 > 若联调发现平台要求接入方计算，再把旧项目 `health_record_complete_level.go`/`health_check_perfection.go` 移植进 `mapping/`（开放问题，见第 8 节）。
 
-### 4.4 `source` —— 任务源
+### 4.5 `source` —— 任务源
 
 - 拉取待上送明细（替代旧项目的本地 mock 文件）。
 - 任务模型：`{taskId, dataType, payload(PHIS原始), ...}`。
 - 投递后回写状态 `done/retry/failed`（旧项目一直 TODO，新项目做实）。
 - `trace_id` 建议直接用 PHIS 任务号，贯穿日志与报告。
 
-### 4.5 `pipeline` —— 投递编排
+### 4.6 `pipeline` —— 投递编排
 
 单条投递流程（继承旧项目 worker 经验）：
 
@@ -170,7 +175,7 @@ type ManageInfo struct { DSFMC, OperateUnit, OperateUser string }
 - **熔断**：连续网络失败达阈值则暂停（阈值/休眠秒可配）。
 - **批次报告**：`total/success/failed/skipped/retry`、失败 Top、逐条明细（沿用旧项目格式）。
 
-### 4.6 `observ` / `store` —— 可观测与存储
+### 4.7 `observ` / `store` —— 可观测与存储
 
 - 一套 report log（收敛旧项目的 apitrace/reportlog/snapshot 三套）：记录每次 PHIS 输入、映射结果、OSI 请求/响应、最终判定。
 - Redis 优先、本地 JSONL 降级；Redis 启动失败不阻断（沿用旧项目）。