FileId は正規化したパスのハッシュとする状態: Accepted
ストアに値を格納するにあたり、FileId の扱いを決める必要があった
（99-open-questions.md Q9）。
FileId は当初 SourceMap 内の添字であり、読み込んだ順に振られていた。
プロセス内では SourceMap::load が
パスに対して同じ識別子を返すため安定していたが、プロセスを跨ぐと
パッケージの走査順に依存する。
格納する値（Document / Value / Prov）はスパンを含み、スパンは
FileId と対でのみ意味を持つ。番号がずれた状態で値を復元すると、
来歴と診断が別のファイルを指す。
選択肢は3つあった。
| 案 | 内容 |
|---|---|
| A. パスのハッシュにする | FileId を読み込み順から独立させる |
| B. 対応表をストアに持つ | 復元時に現プロセスの番号へ振り直す |
| C. 値の中をパスにする | 格納時に置き換え、復元時に引き直す |
案 A を採る。FileId を正規化したパスの 64bit ハッシュとする。
SourceMap の内部は Vec の添字から連想配列へ変わる。
案 B と案 C は、いずれも復元時（案 C は格納時も）に値の木を全走査して
FileId を書き換える必要がある。これは
20-architecture.md 5.1 の「ノードの実体は必要に
なるまで読まない」という性質と衝突する。復元のたびに全走査するなら、
値を遅延して読む意味がない。
案 A では格納した値をそのまま復元できる。走査は生じない。
案 C は加えて、同じパスが値の数だけ重複して保存される。
FileId から SourceMap を引く操作が定数時間から対数時間になる。
診断の描画と来歴の表示で用いるが、いずれも件数が少ないFileId を引いた場合は空の記述を返す。診断の描画中に落とすと
誤りの報告そのものが失われるためである