spec: clarify NHP-LST direction and NHP-LRT response semantics

Summary

The CSA NHP message type summary and Appendix 2 appear to describe different semantics for NHP-LST.

The summary table describes NHP-LST as a server-initiated query used to check NHP-Agent status and validate access requests. However, Appendix 2 describes NHP-LST as an NHP-Agent-initiated request to the NHP-Server for application/resource information. Appendix 2 then describes NHP-LRT as the NHP-Server response to that list/discovery request.

Current OpenNHP main appears to align with the Appendix 2 interpretation:

• nhp/core/packet.go: NHP_LST is commented as agent requesting server listing of services/applications.
• nhp/core/packet.go: NHP_LRT is commented as server replying to agent with listing results.
• HeaderTypeToDeviceType maps NHP_LST to NHP_AGENT and NHP_LRT to NHP_SERVER.
• CheckRecvHeaderType allows NHP_SERVER to receive NHP_LST and NHP_AGENT to receive NHP_LRT.
• nhp/common/nhpmsg.go defines AgentListMsg and ServerListResultMsg, which also suggests request/result semantics.

Why This Matters

The current wording can lead implementers to build incompatible peers:

• One implementation may treat NHP-LST as Server -> Agent status validation.
• Another may treat NHP-LST as Agent -> Server resource discovery.
• NHP-LRT may be interpreted either as a generic bidirectional query-result message or specifically as the server response to NHP-LST.

This affects interoperability, conformance tests, proxies/relays, and any documentation that explains the normal access flow. It also leaves unclear whether NHP-LST participates in access validation, or whether access validation is handled only by the normal NHP-KNK -> NHP-AOP -> NHP-ART -> NHP-ACK flow.

Suggested Acceptance Criteria

• Decide the canonical direction and semantics for NHP-LST and NHP-LRT.
• If Appendix 2 is canonical, update the summary table to describe:
  • NHP-LST as an NHP-Agent -> NHP-Server list/discovery request.
  • NHP-LRT as the corresponding result/response, at least for the NHP-LST flow.
• If NHP-LRT is intentionally generic or bidirectional, document the allowed initiator/recipient pairs for each query type.
• If server-to-agent status validation is intended, document that as a separate flow, or define a separate message type so it is not conflated with list discovery.
• Clarify whether NHP-LST is involved in normal access validation, or whether access validation is exclusively handled through the knock/access-control message flow.
• Add conformance tests or documentation checks that pin the expected direction and receiver behavior for NHP-LST and NHP-LRT.