docs(link): fill in the cliloc PR numbers, correct the cliloc file count

The progress table and CLILOCS.md carried #TBD placeholders until the PRs
existed; they now point at website #115 and docs #70.

Also corrects "all four Cliloc.* files" to eight (chs, cht, deu, enu, esp,
fra, jpn, kor) in both v3.md §8.6 and CLILOCS.md — the compression marker was
checked against every one of them, and understating the sample weakens the
claim it supports.

Co-Authored-By: Claude <noreply@anthropic.com>

website/CLILOCS.md

@@ -1,6 +1,6 @@
 # Cliloc table (item and title names)
 
-**Status:** Complete on `edge` — website [#TBD](https://gitea.whitlocktech.com/RunicGateway/website/pulls).
+**Status:** Complete on `edge` — website [#115](https://gitea.whitlocktech.com/RunicGateway/website/pulls/115), docs [#70](https://gitea.whitlocktech.com/RunicGateway/docs/pulls/70).
 **Design:** [`docs/link/v3.md` §8.6](../link/v3.md) — Protocol 3.0, the dependency Part B/3 was sequenced behind.
 
 A "cliloc" is UO's localization table: an integer id mapped to a display string.
@@ -16,10 +16,11 @@ The number was never the missing piece. The table was.
 
 This is the awkward part, and it is not avoidable:
 
-**Every current UO client ships its cliloc files compressed.** The four
-`Cliloc.*` files in a modern client all begin with a DWORD whose high byte is
-`0x8E` — the "Mythic" compressed container. The plain layout this site parses is
-what those files looked like *before* that change.
+**Every current UO client ships its cliloc files compressed.** All eight
+`Cliloc.*` files in a modern client (`chs`, `cht`, `deu`, `enu`, `esp`, `fra`,
+`jpn`, `kor`) begin with a DWORD whose high byte is `0x8E` — the "Mythic"
+compressed container. The plain layout this site parses is what those files
+looked like *before* that change.
 
 Decompressing it means an inverse-BWT coder with a frequency header — a few
 hundred lines of bit-level work whose failure mode is plausible-looking garbage