v1 authority schema: namespace and security-completeness gaps to weigh for v2

Three review findings on #4 are correct as observations but cannot be acted on within v1: the Go code implements `spec/v1/authority.cddl` exactly, and that file states "Array order is identity-critical. New fields require a new version", with the README adding that accepted lengths must not change without a new protocol version and new vectors. Recording them so the v2 decision is made deliberately rather than by drift.

**1. Registry logic digest does not bind CIP-113 protected asset-name prefixes.**
`cip113-registry-node-logic` covers token policy, minting/transfer/third-party logic, and the global state policy. The spec comment justifies excluding `RegistryNode.next` (linked-list insertion is not security logic), but protected asset-name prefixes are append-only security policy rather than a mutable pointer. As written, changing the prefixes leaves the digest unchanged, so a bound node's third-party behaviour can diverge from the represented profile. Either include the prefixes in the versioned object and digest, or state explicitly that v1 is a narrower, non-security-complete profile.

**2. `asset-name` excludes the empty token name.**
`asset-name = bstr .size (1..32)`, but a Cardano `TokenName` is 0-32 bytes and the empty name is valid and widely used. If CIP-113 uses an empty asset name for the registry origin, v1 cannot represent it. Widening to `(0..32)` is a wire-validation change and needs a version.

**3. Handshake authority names cannot contain an underscore.**
`canonical-wire-name` is specified as "lower-case LDH wire form", and the validator enforces LDH. That is right for ICANN, but `CanonicalHandshakeTLD` in `binding.go` deliberately allows interior `_` (rejecting it only at label boundaries) because Handshake permits it. So a Handshake TLD containing `_` is canonicalizable for the CDNS1 binding but not representable as a `NameAuthority` with `authority-kind: HANDSHAKE`. Options: keep LDH and document the restriction, or make the accepted charset depend on `authority-kind` (Handshake rules including `_` rejection at label boundaries) in a new version.

All three came from cubic's review of #4. The fourth finding in that review (duplicated golden vectors) was actionable in-repo and is fixed in c9ae21c.

Start with spec/v1/authority.cddl and the README's versioning and vector requirements, then inspect binding.go for Handshake name handling. Review cubic's findings and the v1 implementation, including c9ae21c, and decide how each gap should be represented or documented for v2; done means an agreed versioned schema decision with corresponding vectors.

Written by the indexing model from the issue text.