fix: no usernames in Otel

[HatemMn]

Audit should not expose usernames

Merge this after this one to close subissue : #934

[HatemMn]

Review from last-KMS-tester-v5

Ran the full verification pass on this branch's diff (fa263b1b..HEAD, 4 files / 151 lines) — the fix hashes the user OTEL metric label with SHA-256 instead of exporting the raw username.

PR Finding Report — fix/restrict_audit_info

Scope: otel_metrics.rs, Cargo.toml, Cargo.lock, OTLP_METRICS.md
What changed: bounded_user_label() now returns hash_user(user) (truncated SHA-256, 16 hex chars) instead of the raw username, for the kms.kmip.operations.per_user.total and kms.permissions.granted.per_user.total labels. Docs updated to match.

Verification performed

Check	Result
cargo test -p cosmian_kms_server --lib core::otel_metrics	PASS — 13/13, including the 2 updated + 2 new tests (test_user_label_hash_is_deterministic, test_user_label_overflow_stays_literal_sentinel)
cargo clippy -p cosmian_kms_server --lib --all-targets -- -D warnings	PASS — zero warnings
Grep for other raw-username export paths (KeyValue::new("user", other /metrics routes)	CLEAN — the only two call sites already go through bounded_user_label; active_users_tracker (raw usernames) is never read into a KeyValue, only used internally for cardinality/dedup bookkeeping
Cardinality-cap interaction (contains_key check uses raw key, hash only applied to the label)	Correct — the dedup logic and the hashing are independent concerns and don't interfere
Truncation safety (.get(..16) on a 64-char hex string)	Safe, follows the repo's clippy::indexing_slicing convention (.get() + unwrap_or fallback, never panics even if the constant were misconfigured)
Doc/code consistency	Markdown table reformatting is just prettier/mdformat noise; the substantive note about hashing matches the code

Regression check

kms.active.users (the unique-active-user gauge) counts tracker entries only, never labels — unaffected by the hash change. No adjacent behavior touched.

One non-blocking finding

The doc/comment claims the hash is "non-reversible." That's true against an unknown input space, but usernames here are typically emails/OAuth subjects — a low-entropy, guessable space. Anyone with a candidate identity list can hash each candidate and match against exported labels (dictionary attack), so this is pseudonymization, not strong de-identification. Not a regression from this PR's stated goal (raw usernames no longer appear verbatim in the OTLP backend), but worth knowing if the threat model requires resistance against a motivated insider with a user list. If that matters, consider HMAC-SHA256 with a server-side secret instead of a plain hash.

Verdict: GO — small, well-tested, no regressions found; the reversibility caveat above is worth a follow-up note but doesn't block this fix.

[HatemMn]

I'm sick of solving this merge commit I will open a new PR