dlt_daemon_control_set_log_level_v2 never assigns req.apid/req.ctid; silently fails or crashes the daemon

[SoundMatt]

Summary

dlt_daemon_control_set_log_level_v2 in src/daemon/dlt_daemon_client.c
does not actually parse the apid / ctid fields out of incoming
SET_LOG_LEVEL V2 control requests. As a result:

• A request with apidlen == 0 and ctidlen == 0 is silently no-op'd
  (the function falls through to a path that calls
  dlt_daemon_context_find_v2 with NULL apid/ctid).
• A request with apidlen != 0 causes a NULL pointer dereference at
  line ~3723 and crashes the daemon.

The function is reachable from any client that can talk to the daemon's
control socket (dispatched from dlt_daemon_handle_control_messages_v2
at line 1273 of the same file).

Evidence

The DltServiceSetLogLevelV2 struct
(include/dlt/dlt_common.h:760-769) declares apid and ctid as
pointers, not inline arrays:

[minminlittleshrimp]

Hi @SoundMatt
regarding the PRs, please kindly put all commits into 1 PR for easier tracking.

[SoundMatt]

Hi @minminlittleshrimp, the four V2 control-handler PRs (#861, #862,
#864, #868, #869) are intentionally split per-function, with #866 as
the META-Issue that ties them together for family-level tracking.
Each individual PR cross-references #866 and the others, so the
family context is one click away from any of them.

If "easier tracking" is what's needed, #866 is the entry point —
every PR in the family links there, and the META-Issue lists each
one. Collapsing five already-open PRs into one would (a) lose
per-function reviewability — a single review comment on any one
function would block all five from merging — and (b) is significant
rebase / cherry-pick work for the contributor, at the cost of a
tracking gain that #866 already provides.

Happy to iterate on each PR individually as review feedback comes
in. If there's a specific aspect of #866 that isn't meeting your
tracking need, let me know and I can extend the META-Issue.
Otherwise the per-function structure is the right shape for these.