feat(types): Dict + Set string-keyed containers (#54)

Types phase 4 — containers. A splice-on-demand open-addressing hash table
(runtime/native/dict.ludic, FNV-1a, linear probing, tombstones, grow at 0.7)
behind two namespaces:

- Dict.* — string -> int map: new/set/get/get_or/has/remove/size/clear/keys.
  Resource counts, id/name registries. O(1) average vs a linear list scan.
- Set.* — set of strings: new/add/has/remove/size/clear/members. Tags,
  unlocked achievements, visited tiles. Shares the same table.

Values are int (also an entity handle / small id); Value.* covers richer
maps. [T; N] inline fixed arrays remain future work — typed buffers and []T
slices already cover heap-backed arrays.

Wired: parser splice trigger (g_uses_dict), emit_call dispatch, reseeded seed,
a self-asserting example (examples/library/containers.ludic + feat_case), and
per-symbol docs + inventory. All suites green incl. golden renders byte-
identical and the bootstrap fixpoint.

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

docs/language/dict/_section.md

@@ -0,0 +1,7 @@
+---
+id: dict
+title: Dict
+order: 12
+---
+
+A hash map from string keys to <code>int</code> values — the everyday lookup a game needs, like resource counts or an id registry by name. A <code>Dict</code> is backed by an open-addressing hash table (FNV-1a, linear probing, tombstone deletes, growing at load factor 0.7), so <code>get</code>/<code>set</code>/<code>has</code> are O(1) on average rather than the linear scan a list would give. Create one with <code>Dict.new</code>, then <code>set</code> / <code>get</code> / <code>get_or</code> / <code>has</code> / <code>remove</code> / <code>size</code> / <code>clear</code> / <code>keys</code>. Values are <code>int</code> (which also holds an <code>entity</code> or any small id); for richer values use the <code>Value.*</code> tree. Arguments are positional. The runtime is spliced in only when a program mentions <code>Dict.*</code> (or <code>Set.*</code>).