lib: fix heap buffer overflow in dlt_with_filename_and_line_number

[SoundMatt]

Problem

dlt_with_filename_and_line_number() in src/lib/dlt_user.c writes
past the end of a heap allocation when strlen(fina) > 255:

dlt_user.filenamelen = (uint8_t)strlen(fina);          // truncates
...
dlt_user.filename = malloc(dlt_user.filenamelen + 1);  // small
strcpy(dlt_user.filename, fina);                       // full

filenamelen is uint8_t (matches the V2 wire-format field width
declared in include/dlt/dlt_user.h.in:235), so the cast truncates
strlen(fina) modulo 256. The subsequent malloc allocates the
truncated length + 1, but strcpy copies the entire fina including
its real terminator — writing strlen(fina) - filenamelen bytes past
the end of the heap chunk.

Reachable in practice via long compile-time __FILE__ paths
(monorepo-rooted absolute paths regularly exceed 255 chars) and any
application that forwards a user-controlled filename through this
function. Heap-write primitive in the linked-into-everything client
library.

Fix

Clamp strlen(fina) to UINT8_MAX before assigning filenamelen,
allocate against the clamped length, and copy with memcpy + explicit
null terminator instead of strcpy. The on-wire field still gets the
maximum the V2 protocol can encode.

Notes

• I have not added a unit test in this PR. If maintainers can point me
  at a harness for dlt_user.c (e.g. via gtest_dlt_user.cpp) I'm
  happy to follow up with one.
• Per-call filename length (dlt_user_param.filenamelen at line
  6555) appears to use the same uint8_t width. Worth a separate
  audit pass to confirm callers can't trigger the same pattern; not
  in this PR's scope.

[minminlittleshrimp]

The PR is good in Root cause Analysis, please rework with strncpy and then we can merge.
Thank you

[minminlittleshrimp]

remove reinit of this var, this var is function opt agr

[minminlittleshrimp]

This pattern is not good.
filename is a string, use strncpy for truncation here + 1 null padding in next line is the common pattern.
e.g.

strncpy(dlt_user.filename, fina, fina_len-1);
dlt_user.filename[fina_len] = '/0';

[SoundMatt]

Thanks for the detailed feedback! Applied both changes in the latest push:

1. Removed fina_len intermediate variable — filenamelen is now set directly via a ternary that clamps at UINT8_MAX, eliminating the separate local variable.
2. Switched to strncpy — replaced memcpy + explicit null with strncpy(dlt_user.filename, fina, (size_t)dlt_user.filenamelen) followed by the explicit null terminator at [filenamelen], which is the conventional C string-truncation idiom.