Say why an empty name is rejected, and finish what that removed

The reason given was wrong. A dot path did reach an empty-named field:
Fake("a.") returned it, Fake("a.b.") returned a nested one, and {..a.} bound
it. What was true is narrower — List never offered it, because an empty name
is no path segment — so the engine accepted spellings it would not advertise.
The message, the test comment and the README say that instead.

Two things the rejection finished off:

A {} token still reported "no field \"\"", pointing at a fix the loader now
rejects — two errors for one rule. It is told the name can never exist, like
an option token already is.

addressable is dead: both halves of "not empty and no dot" are now rejected
where a name is authored. Mutating it to panic leaves the suite green here
and panics on main, so it was live and is not. Keeping it would preserve the
silent-hiding this change removes — List quietly omitting a name rather than
New refusing it.

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

README.md

@@ -238,8 +238,9 @@ option stays unset. `New` rejects an option that cannot take effect — a
 `separator` without a `repeat` above 1, a `weight` outside a choice — and a name
 using a character the grammars reserve: `.` separates the segments of a path, `|`
 the arms of a token, `(` opens a function call and `}` ends the token, so a name
-carrying one is a name no format could ever spell. That holds for a category, a
-folder and a field alike.
+carrying one is a name no format could ever spell. An empty name goes the same
+way — it is no path segment at all, so `List` never offers it. That holds for a
+category, a folder and a field alike.
 
 **Functions.** A `{name()}` token calls a built-in function instead of rendering
 a field. `{luhn()}` appends a Luhn check digit over the digits emitted **so far**