normative: floor presence is malformed, mint malformed-entry

A floor artifact missing a required field was implicitly missing-required-field,
the action-relative reason. But the floor has no role that reads a partial field
table, so its required fields are fixed by the meta-table, not by an actor. The
floor is the degenerate case where presence collapses into malformedness.

Mint malformed-entry for an entry missing key/name/type/presence, restoring one
malformed-* reason per floor shape. Extend malformed-field-table to cover a
missing describes/version/entries and an empty entries list, and
malformed-type-descriptor to cover a missing kind and a commission (a kind
carrying a field it forbids), not only an omission.

Refs canonical-encoding.md Interpretation refusals.

Signed-off-by: Chris Raynor <chris@raynor.tech>

Author: cbraynor

canonical-encoding.md

@@ -314,12 +314,13 @@ These reasons are a function of the artifact bytes and the version-closed field
 - `bad-magnitude`: a field the table declares decimal or rational whose value is not a two-element array of integers (Structure on the wire, meaning in the schema, above).
 - `non-canonical-decimal`: a decimal outside its canonical form, a mantissa divisible by ten, or a zero in any form other than `[0, 0]` (Domain-declared magnitudes, above).
 - `non-canonical-rational`: a rational outside its canonical form, a denominator that is zero or negative, a numerator and denominator sharing a common factor, or a zero in any form other than `[0, 1]` (Rationals, above).
-- `malformed-type-descriptor`: a type-descriptor in the floor that omits what its kind requires, such as an array kind carrying no element type (The closure, above).
-- `malformed-field-table`: a field table whose entries do not form the dense, ascending, duplicate-free key sequence a table requires, or otherwise break a field-table rule the meta-table's flat field types cannot state (The closure, above). Each entry decodes and type-checks against the entry table, so neither the byte decoder nor the per-field type check refuses it, and only the field-table's own shape rule does.
+- `malformed-type-descriptor`: a type-descriptor in the floor whose fields do not match its kind. The kind is absent, a field the kind requires is missing (an array carrying no element type), or a field the kind forbids is present (a scalar carrying an element type or a unit). (The closure, above.)
+- `malformed-field-table`: a field table that is not a dense, ascending, duplicate-free key sequence of entries, that carries no entries at all, or that is missing a field the meta-table requires (`describes`, `version`, `entries`). Each entry decodes and type-checks against the entry table, so neither the byte decoder nor the per-field type check refuses it, and only the field-table's own shape rule does.
+- `malformed-entry`: a field-table entry missing a field the meta-table requires (`key`, `name`, `type`, `presence`). The entry decodes cleanly, but no field table can be built from an entry that lacks one of these, and no generic reason names the absence.
 
-`malformed-type-descriptor` and `malformed-field-table` share a class. Each names a floor artifact that decodes cleanly and matches the meta-table field by field, yet breaks a structural rule of its floor type the flat field-table model cannot carry: a type-descriptor's required `of`, `ref`, or `unit` is conditional on its `kind`, and a field table's entry keys must be dense and ascending. There is one such reason per floor shape that has such a rule. The entry shape has none beyond the generic reasons, so there is no `malformed-entry`. One is added only if an entry rule appears that the flat model cannot state.
+`malformed-type-descriptor`, `malformed-field-table`, and `malformed-entry` share a class, one reason per floor shape. Each names a floor artifact that decodes cleanly and matches the meta-table field by field, yet breaks a structural rule of its floor type the flat field-table model cannot carry. Two kinds of rule live here. The first is a constraint the flat presence column cannot state: a type-descriptor's `of`, `ref`, or `unit` is required or forbidden by its `kind`, and a field table's entry keys must be dense and ascending. The second is presence itself. On the floor presence is not action-relative as it is for a protocol artifact (Action-relative reasons, below): a field table has no role that reads a partial copy, so the meta-table's required fields are fixed by the bytes and the table, and a floor artifact missing one is malformed, not action-missing. The floor is the degenerate case where presence collapses into malformedness (the degenerate-case law, specification Section 1).
 
-A floor artifact is interpreted against the meta-table exactly as any artifact is interpreted against its table, so the generic reasons above apply to it unchanged. An `entries` element that is not an entry map is `type-mismatch`, and a wire key a floor table does not define is `unknown-field-key`. An integer a floor field cannot resolve is neither: `type-mismatch` is a wrong structure, not a wrong value. An artifact-type code in `describes` or a `ref` the node holds no table for is `unresolved-ref` (Capability-relative reasons, below), and a `presence` code outside the version's enum is the same resolution family. The `malformed-*` reasons are reserved for the rules the flat model cannot state.
+A floor artifact is otherwise interpreted against the meta-table exactly as any artifact is interpreted against its table, so the generic reasons above apply to it unchanged. An `entries` element that is not an entry map is `type-mismatch`, and a wire key a floor table does not define is `unknown-field-key`. An integer a floor field cannot resolve is neither: `type-mismatch` is a wrong structure, not a wrong value. An artifact-type code in `describes` or a `ref` the node holds no table for is `unresolved-ref` (Capability-relative reasons, below), and a `presence` code outside the version's enum is the same resolution family. A required field absent from a floor artifact is `malformed-*`, not `missing-required-field`, which is reserved for the protocol artifacts whose presence is action-relative.
 
 The decimal and rational cases carry the same content-addressing weight as the byte-level reasons, one layer up. A magnitude has exactly one canonical form, so it has one content address. An interpreter that accepts a second form, the non-canonical `[-3, 150]` for the decimal `[-2, 15]`, forks that address along implementation lines, which is the fork the whole canonical form exists to forbid (The content address, below). They are therefore the load-bearing schema fixtures, and lead the schema reject vectors.