Add authenticated server identity discovery

[Jason-Morcos]

Addresses the first half of #75.

Why

The two WD53-family appliances I have running locally present a trusted Samsung
hardware certificate during the first manufacturer-certificate session, but
the certificate UUID is not available to the caller before that handshake.
The certificate UUID also has to be treated separately from the OCF device UUID
read from /oic/d.

SamsungServerProfile.bound_device() remains the right profile after that
binding has been established. The missing piece was a way to make the initial
authenticated connection without weakening the normal pinned profile.

What changes

• adds SamsungServerProfile.discover_device() for that explicit first-use
  connection;
• preserves the existing CA-chain and exact C=KR, O=Samsung Electronics,
  selected OU role checks;
• rejects an unreadable subject or a missing, malformed, or nil UUID in the
  verified leaf;
• exposes the verified subject UUID as
  DtlsCoapSession.server_certificate_identity after connect() succeeds;
• keeps the authentication profile immutable and reusable without retaining a
  learned peer identity; and
• documents binding the result to /oic/d evidence from the same authenticated
  session, then returning to bound_device() for normal connections.

Both client-certificate and server-only certificate providers use the same
profile contract. Existing unprofiled sessions continue to expose None.

This does not perform ownership transfer, write OCF security resources, or
persist the learned association.

Validation

• 682 tests pass on Python 3.14
• certificate-profile tests cover two distinct verified identities, malformed
  subjects, nil UUID, wrong device role, provider reuse, and both certificate
  provider shapes
• session tests cover publication only after a completed handshake and
  fail-closed cleanup for missing or malformed post-handshake identity
• share-safety check passes against main

Merge order

This is the first PR in the #75 stack. The HVR-only peer cleanup follows it;
the final public API/documentation pass follows both. #74 is independent.