docs(developer): 三处与实现对不上——quickstart 去掉已退役的 src/arch/linux/ld/ · faq .ccr 版本 v6→v9 · corec2 条目加修订注

[dslsdzc]

这是什么

docs/developer/ 里三处与实现对不上的地方。不是风格改动，是事实更正与历史加注。来源 = 文档风格审查批 1 顺带查出的三条（R2），我逐条复核后动手。

三处

#	位置	原文	改后
①	quickstart.md:55 目录表	| src/arch/linux/ld/ | ELF 后端(指令编码/链接) |	改指后端三轴 src/arch/ · src/format/ · src/os/，并加注说明 src/arch/linux/ld/ 已退役、组合根在 src/targets/x86_64-linux/
②	faq.md:39	「.ccr 内容随 v6 段表推进」	v9，并指出版本以 src/compiler/ccr_io.cr 的 CCR_VERSION 为准
③	faq.md:34 corec2 问答	原文保留不动	加一条修订注：该问题不再作为阻塞项（corec2 == corec3 IDENTICAL，由 src/ci/run.sh 的 full-bootstrap job 覆盖）

① 的依据：jj file list -r develop@origin | grep -c '^src/arch/linux/ld/' = 0（该目录在树上已不存在）。
② 的依据：src/compiler/ccr_io.cr:135 = CCR_VERSION : int = 9;。
③ 为什么是加注不是改写：那段原文已经用了过去时（「它曾有 tokenizer 死循环已知问题」），事实陈述没写错；错的是问题式标题（「为什么我 check 会卡住」）暗示它还在发生。⇒ 按本仓「原文保留 + 加注」惯例处理，不删史。

⚠ 顺带更正一条转述：审查代理把 ③ 报成「疑似陈旧事实」，复核后不成立（见上）。①② 成立。

验核：用刚建的那条判据验我自己的改动

批 1 新入仓的 tools/doc_protected_surface.py（文档非散文面抽取 / 对拍）正好可以量这次改动的波及面：

extract --rev develop@origin            (改前)
extract --rev feature/devdocs-stale-facts (改后)
compare --floor 1 --per-file-floor 0
⇒ FAIL  受保护面有差异：- 2 项 / + 22 项

差异逐条全部对得上意图，无多余波及：

• - NUM faq.md | 6 → + NUM faq.md | 9（v6→v9）
• - TROW quickstart.md | <旧行> → + TROW quickstart.md | <新行>
• + INLINE ×8：我新写进注里的引用（CCR_VERSION / corec2 / corec2 == corec3 / full-bootstrap / src/ci/run.sh / src/compiler/ccr_io.cr / src/arch/linux/ld/ / src/targets/x86_64-linux/）
• + MARKER ×1：新增的修订注整行（该工具把「修订/加注」行也列为受保护面 —— 正合本仓惯例）
• + NUM ×若干：新增注里的日期与 x86_64 里的数字

⇒ 这条判据在此判红是预期（改事实面本来就该动受保护面），它的价值是证明改动边界 = 意图边界。

未做

• 标点半角/全角统一（批 1 的 R1）：8 档半角 · 3 档全角 · 2 档档内混用。方向须维护者定，本 PR 不碰。
• 其余 12 档风格面：批 1 审下来零命中，未改。