portal. summon a face

What this proves

• Summon, don't hardcode. Type @ and a name — the face binds to that rail record by command. The summoned face is the same stateless kind: edit, persist, reload, destroy/remount all still hold on it. That's the master key turning (syntax summons the face; the rail is the door).
• Never a silent pick. If a query matches more than one record, every match is shown and you choose — the system never binds an ambiguous name for you. A name that matches nothing offers to create a new face.
• One record set. The face reads and writes the real Supabase rail at /api/spine/records — the same wire inputdojo writes and the manymoats console reads. No second copy of the data.
• Faces are stateless over records. Destroy face tears the whole face out of the DOM; Remount rebuilds it from nothing but its binding and re-reads the rail. Your edit comes back because it never lived in the face — it lives on the rail.
• The binding is an address. The face is bound to {recordType, recordId} carried in the URL. Summoning rewrites the address, so a reload re-reads the summoned record. It never renders raw content — only a record resolved from its binding.
• Honest scope. This is the portal's summon seam over the rail — @-summon and create only. The full @// grammar (generative @image, /simplify, delimiter-commit) is the shared CommandSystem engine, folded in later so every face gains it at once. Nothing here is a stub — every control writes real records.