docs: record the scheduler search optimisation

docs/design/parallel.md

@@ -51,7 +51,8 @@
   典型是 SGP4 传播（约 230 ns/样本，百万样本量级）与可见性搜索（约 7 μs/轨）。
 - **不值得并行**：
   - `Constellation::instantiate`：纯算术，几百颗星只需微秒，线程开销完全淹没。
-  - 调度器：贪心放置本质串行，每次放置影响后续，不是独立循环。
+  - 调度器：贪心放置本质串行，每次放置改变后续任务的可行区间，不是独立
+    循环，因此没有并行接口；但其中的搜索已改为单次扫描（见下）。
   - 事件引擎：单队列时序，无法分块。
   - 大地与坐标变换：单点调用本身已是 O(1)，没有批量。
   - `mutual_visibility` 单次：约 4 ns，**单次**不值得，但成矩阵（见下）。
@@ -96,3 +97,25 @@
 的布尔矩阵、access 的过站摘要），顺序也一致。传播本身是确定性的，只依赖时刻，
 与如何分块无关；可见性与过站搜索是逐元素独立的。因此同一输入在任意线程数下
 产生相同输出，测试也按此断言。
+
+## 调度器搜索的优化
+
+调度器没有并行接口，但它的最坏情况曾达到每任务数百微秒。优化分两步，两者都
+保持结果逐位不变。
+
+**第一步：一次扫描代替逐候选测试。** 旧的做法列出所有"可行性可能变化"的时刻，
+逐个测试，每次都重新计算每个资源的负载曲线。负载曲线与候选时刻无关，因此改为
+扫一次：把"资源没有余量的区间"从可用窗口中减去，多资源求交，取第一个存活区间
+的起点。结果仍由 `feasible_at` 确认，枚举法保留为浮点边界不一致时的回退。
+
+**第二步：确认调用复用索引。** 去掉确认调用后耗时降到八分之一，这定位了真正
+的开销：确认用的公开可行性测试在收集边界时扫描一次任务表，又在每个边界上对每
+个覆盖该边界的放置再扫描一次任务表。把第一步建好的索引传进去，两处扫描都变成
+按标识符直接读取。
+
+任务标识符是小而稠密的整数，因此索引用向量而非哈希表：数组下标比哈希一个整数
+更便宜，这在本仓库已测到两次（拓扑的邻接表用索引、这里的任务表用向量）。
+
+**结果**：全部任务争用单一资源、容量为瓶颈时，3200 个任务从 6.7 秒降到 0.48
+秒（14 倍），6400 个任务 2.2 秒。计划结果不变——测试在两种资源、窗口不相交的
+场景下逐个比对了每个放置的起止时刻。