[Defect]: LMOTS pattern uses treeHeight semantics and misses W (RFC 8554 / SP 800-208)

## Describe the defect

In `schema/cryptography-defs.json`, the `LMS` family includes an `LMOTS` variant pattern that appears to encode parameters in a way that does not line up with how LM-OTS parameter sets are identified in the referenced standards.

Current registry patterns:
- `LMS[_{hashFunction}][_M{bytesPerNode}][_H{treeHeight}]`
- `LMOTS[_{hashfun}][_N{bytespernode}][_H{treeheight}]`

For LMOTS, the pattern currently includes `_H{treeheight}` and uses `_N{bytespernode}`, while omitting `W`. This seems inconsistent with standard LMOTS parameter-set identifiers (which include `N` and `W` alongside the hash function).

## Additional context

### References

- **RFC 8554 (LMS Hash-Based Signatures)**
- **Table 1 (LMOTS parameter sets)** lists columns including `H` (hash function), `n`, `w`, and `p`, and shows names such as `LMOTS_SHA256_N32_W4`. (RFC 8554, Table 1)
- **Table 2 (LMS parameter sets)** lists columns including `H` (hash function), `m`, and `h` (tree height), and shows names such as `LMS_SHA256_M32_H5`. (RFC 8554, Table 2)

- **NIST SP 800-208**
- Section 4 (“Leighton-Micali Signatures (LMS) Parameter Sets”) includes:
- **Table 1** (LM-OTS parameter sets for SHA-256): `n, w, p` and names like `LMOTS_SHA256_N32_W4`
- **Table 2** (LMS parameter sets for SHA-256): `m, h` and names like `LMS_SHA256_M32_H5`
- Tables 3–8 extend the same structure for other approved hash functions.

### `_H{treeheight}` is problematic for LMOTS
Tree height (`h`) is an LMS-level parameter (Merkle tree height). LM-OTS is a one-time signature and does not have a tree height parameter. In the RFC tables, `H` in the LMOTS table refers to the hash function, not height—so using `_H{treeheight}` in the LMOTS pattern may cause confusion for consumers that interpret these patterns.

### Note on `p`
`p` appears in the LMOTS tables, but standard LMOTS parameter-set names typically encode `N` and `W` (e.g., `..._N32_W4`). A pattern capturing `hash + N + W` is usually sufficient, with `p` optionally included only if needed.

### Question
Is the LMOTS `variant.pattern` intended to reflect standard LMOTS parameter-set identifiers? If yes, would maintainers prefer encoding something closer to `hash + N + W` (and optionally `p`) rather than tree-height terminology?