[Mehrn0ush]

SSH has no cipher suites. It negotiates algorithms independently per category in SSH_MSG_KEXINIT (RFC 4253 section 7.1). Today a producer can only put SSH algorithms into cipherSuites or relatedCryptographicAssets, so a consumer cannot tell a key exchange method from a host key algorithm or a cipher.

This PR adds an optional protocolProperties.sshAlgorithms object with one list per KEXINIT name-list category:

• kex (kex_algorithms)
• hostKey (server_host_key_algorithms)
• encryption
• mac
• compression

Each entry has a required name (the name as it appears in the SSH name-list, preferably from the IANA SSH Protocol Parameters registry) and an optional algorithm reference to an algorithm asset. This is the same shape as the existing ikev2TransformTypes entries.

Semantics:

• Lists are as configured or observed for the subject of the BOM. Order does not convey preference, and the lists do not identify what was selected in a connection.
• Encryption, MAC and compression are recorded without distinguishing direction.
• Extension indicators in kex_algorithms (e.g. ext-info-s, RFC 8308) are not recorded.
• User-authentication algorithms (RFC 4252) are out of scope.

The category is carried by the property name, so no free-text role vocabulary is introduced.

Fixtures: one valid document, including the two cases from #1162 (comment) (mlkem768x25519-sha256 as key exchange, ssh-ed25519 as host key), and three invalid documents (bare string item, missing name, unknown category).

Addresses the SSH portion (problem 2) of #1162 without closing the issue.