singleton: guard the state, not the program's name

The singleton lock protected a filename, not a store. It was keyed on
$EL_SINGLETON_DIR|$TMPDIR|/tmp + /el-singleton-<program>.lock — the
program's NAME and a temp directory — and never consulted the state it
claimed to protect, while its own refusal message read "Refusing to start
a second instance against the same state."

Measured, it failed in both directions. A second engram against a
DIFFERENT data dir was refused, naming the first's pid. And
TMPDIR=/tmp/other let a second engram start against the SAME data dir
with no complaint — the two-writer data-loss condition the guard exists
to prevent, defeated by one environment variable.

Both are one error: the identity of the resource had been replaced by a
label for it.

The lock now lives inside the state it guards —
<state>/.el-singleton-<id>.lock — and the program block says what that
state is. Same directory is the same file is the same inode, so it
contends and there is no TMPDIR left in the key to change. Different
directories are different files, so they don't. Different spellings of
one directory (trailing slash, x/../x, symlink) collapse in the kernel's
own path walk, so they contend without this code comparing strings;
canonicalisation is for the message, never the decision.

`guards:` is an expression so a program can point at the resolver that
already owns its path — guards: engram_resolve_data_dir() — instead of
restating that resolver's default, which is the two-owners defect spec
18.4 exists to prevent. A `singleton:` without `guards:` is now a compile
error; emitting a name-keyed lock instead would be emitting the defect.

Kept: the flock (the kernel drops it on crash and SIGKILL, so there is
still no "delete the lock file to get unstuck" ritual — a stale file
inside a copied data dir is inert), and the holder's pid in the message.
Changed: the message is true. It says "the same state" because the lock
it failed to take is in that state, and it names the state it checked.
An unguardable state (missing, read-only) now refuses rather than
starting unguarded.

Also corrects lang/AGENTS.md's compiler rebuild line, which had gone
stale: linking el_runtime.c alone no longer resolves.

engram/src/server.el

@@ -23,16 +23,26 @@
 // warning. The runtime takes an exclusive flock at startup and a second start
 // is refused loudly with the holder's pid.
 //
-// NOT declared here, on purpose: ENGRAM_DATA_DIR. Its resolution is owned by
-// engram_resolve_data_dir() (el_runtime.c), which defaults to $HOME/.neuron/engram
-// and fails LOUD rather than silently persisting to an ephemeral directory.
-// Declaring a default for it here as well would put the data dir's fallback in
-// two places — which is precisely the defect this migration removes (until
-// 2026-08-15 the reseed backup path carried its own "/tmp/engram" default that
-// disagreed with the resolver, so the pre-destructive safety copy landed in /tmp).
+// guards: names WHAT the singleton protects — this program's data directory. The
+// lock lives inside it, so the guard is keyed on the store and not on the word
+// "engram": two engrams against the same store cannot both run no matter how the
+// environment is spelled, and two engrams against DIFFERENT stores are not each
+// other's business and are not refused. Until 2026-08-16 the lock was keyed on
+// the program name and $TMPDIR, and both of those sentences were false.
+//
+// It names the resolver rather than restating its path, for the same reason
+// ENGRAM_DATA_DIR is NOT declared as an `env` entry below: engram_resolve_data_dir()
+// (el_runtime.c) owns that path — it defaults to $HOME/.neuron/engram and fails
+// LOUD rather than silently persisting to an ephemeral directory. Restating the
+// default here would give the data dir two owners that can disagree, which is
+// precisely the defect this migration removes (until 2026-08-15 the reseed backup
+// path carried its own "/tmp/engram" default that disagreed with the resolver, so
+// the pre-destructive safety copy landed in /tmp). A guard that resolved the path
+// its own way could guard a directory the program never writes to.
 // HOME is likewise not declared: it is a genuine environment read, not a knob.
 program "engram" {
     singleton: "engram"
+    guards: engram_resolve_data_dir()
 
     // ── Core server ──
     env ENGRAM_BIND: String = ":8742"