[Feat]: Update dotns-sdk subname issuance for the new SubnodeRecord shape and lite subnames

Component

Registration

Priority

P1

Summary

The dotNS contracts changed how names below the top level are issued, and the dotns-sdk must be
updated anywhere it issues a subname or reads a lite (PoP) name.

Two contract-side changes drive this:

1. IDotnsRegistry.SubnodeRecord gained a persist field. When true the registry indexes the
   subnode into the owner's LabelStore; when false it writes only the ownership and resolver
   record and the caller writes the label into the store separately. Every setSubnodeOwner call
   must now supply this field.
2. A PoP lite username (alice.01) is now issued as a subname alice beneath the numeric
   container 01, not as one atomic label. Its node is
   namehash(namehash(tldNode, keccak("01")), keccak("alice")), and its ownership lives in the
   registry record, not as an ERC-721 token on the registrar.

Desired outcome: the SDK constructs the current SubnodeRecord shape, and resolves and reads
ownership of a lite name at its subname node through the registry.

Proposal

The new struct shape:

struct SubnodeRecord {
    bytes32 parentNode;
    string subLabel;
    string parentLabel;
    address owner;
    bool persist;
}

• Update every place the SDK builds a SubnodeRecord / calls setSubnodeOwner to include
  persist, choosing true or false per the caller's store-indexing need.
• For a lite name <stem>.<suffix>, split on the separator and derive the node as
  namehash(namehash(tldNode, keccak(suffix)), keccak(stem)) rather than hashing the whole label
  under the TLD.
• Read a lite name's owner from the registry (owner(node)), which resolves both a tokenised name
  and a subname, rather than from the registrar's ownerOf.

Acceptance criteria

• The SDK builds against the current SubnodeRecord (with persist) and every call site sets it.
• Subname issuance and lite-name resolution derive the subname node by splitting on the separator.
• Lite-name ownership is read from the registry, not the registrar.

Start by locating every SubnodeRecord construction and setSubnodeOwner call, then inspect the lite-name resolution and ownership entry points. Update those paths for persist, derive lite nodes by splitting the name into suffix and stem, and read ownership through the registry; the SDK should build against the current struct and satisfy all listed acceptance criteria.