fix(endpoint_manager): scope client_endpoints_ by service to prevent socket sharing (#899)

[aki1770-del]

Problem

When two SOME/IP services are offered on the same remote address:port, a client subscribing to both services incorrectly shares a single UDP socket between them.

Root cause — client_endpoints_ in endpoint_manager_impl is keyed by [remote_address][remote_port][reliable][partition_id]. When find_remote_client() is called for a second service whose server endpoint shares address and port with the first, it finds the existing endpoint object and registers it under the second service. create_remote_client() is never called for the second service, so:

• The second service's configured local port is never opened.
• Both SubscribeEventgroup messages are sent from the first service's socket.
• The second client's local port is never used (Wireshark shows zero traffic from it).

Reported against v3.4.10 on Embedded Linux with two services (0x9002, 0x9003) both offered on UDP port 35699 — closes #899. Related to #380.

Fix

Add service_t as the outermost key of client_endpoints_t:

// Before:
using client_endpoints_t = std::map<boost::asio::ip::address,
    std::map<uint16_t, std::map<bool, std::map<partition_id_t,
        std::shared_ptr<boardnet_endpoint>>>>>;

// After:
using client_endpoints_t = std::map<service_t,
    std::map<boost::asio::ip::address,
        std::map<uint16_t, std::map<bool, std::map<partition_id_t,
            std::shared_ptr<boardnet_endpoint>>>>>>;

Six usage sites updated: find_remote_client, create_remote_client, clear_client_endpoints, print_status, log_client_states, resume.

Partition-sharing behaviour preserved: existing logic that lets multiple instances of the same service share a client endpoint (via the partition key) is unaffected — the new outermost key is identical for same-service lookups.

Verification

After the fix, client_endpoints_[0x9002][addr][35699][false][P0] and client_endpoints_[0x9003][addr][35699][false][P0] are independent map entries. The second service falls through to create_remote_client() and obtains its own socket bound to its configured local port. Both subscription messages are sent from the correct per-service source ports.