Unauthenticated Remote Logstorage Path Injection in dlt-daemon

## Summary

`dlt_daemon_control_service_logstorage` trusts the `mount_point` supplied through the unauthenticated TCP control port (default 3490) without sufficient validation.

As a result, an attacker can designate an arbitrary directory as a logstorage root, causing the daemon to read its configuration and create `.dlt` files with its execution privileges. This makes the existing offline-logstorage arbitrary-write (symlink #901) vulnerability remotely exploitable without requiring physical media.

## Vulnerable Code
File: `src/daemon/dlt_daemon_client.c`

```c
4781: req = (DltServiceOfflineLogstorage *)(msg->databuffer);
4782:
4783: if(req->connection_type != DLT_OFFLINE_LOGSTORAGE_SYNC_CACHES) {
4784: req_st_status = stat(req->mount_point, &req_mpoint_st); /* only existence is checked */
....
4858: if (req->connection_type == DLT_OFFLINE_LOGSTORAGE_DEVICE_CONNECTED) {
4859: ret = dlt_logstorage_device_connected(device, req->mount_point); /* accepted as-is */
```

`mount_point` is accepted after only a successful `stat()` check, which verifies only path existence. No validation is performed to ensure that it is a legitimate mount point, trusted location, or non-symlink path.

## Root Cause

1. `stat()` only verifies that `mount_point` exists; it does not verify that it is a legitimate storage device or trusted path.
2. The control channel does not provide authentication or authorization for storage path selection.
3. As a result, `dlt_logstorage_device_connected(device, req->mount_point)` accepts an attacker-controlled directory as a logstorage root and writes DLT files there with daemon privileges.

## Reproduction

1. Run the daemon with `OfflineLogstorageMaxDevices = 1`.
2. Create an arbitrary directory containing a valid `dlt_logstorage.conf`.
3. Send a `DLT_SERVICE_ID_OFFLINE_LOGSTORAGE` (`0x0F05`) device-connect control message specifying the directory as `mount_point` (see packet capture below).
4. Generate a matching log message and observe that `.dlt` files are created in the attacker-controlled directory.

## Log

The packet capture below shows an unauthenticated TCP request to port 3490 carrying `DLT_SERVICE_ID_OFFLINE_LOGSTORAGE` (`0x0F05`) with `/storage` as the attacker-controlled `mount_point`.

The daemon accepts the attacker-controlled directory as logstorage and creates DLT files there with the daemon's privileges, confirming that `mount_point` is used without sufficient validation.

Start in src/daemon/dlt_daemon_client.c around the DLT_SERVICE_ID_OFFLINE_LOGSTORAGE handling at lines 4781-4859, and review how the unauthenticated control request reaches dlt_logstorage_device_connected. Reproduce with OfflineLogstorageMaxDevices=1 and an attacker-controlled directory containing dlt_logstorage.conf. Done means the remote request can no longer select an arbitrary logstorage path or cause privileged .dlt writes there.

Written by the indexing model from the issue text.