fix: accept non-string values in Header extras

[kp-timo-beyel]

Summary

• Change Header.extras from HashMap<String, String> to HashMap<String, serde_json::Value>
• decode_header / decode now accept JWT headers with non-string custom fields (e.g. "uid": 180444)

Problem

When a JWT header contains a non-standard field with a non-string value such as:

{"typ": "JWT", "alg": "RS256", "kid": "...", "uid": 180444}

decode_header fails with a deserialization error because serde cannot coerce the integer 180444 into a String for the #[serde(flatten)] pub extras: HashMap<String, String> field.

JOSE headers can legitimately carry arbitrary JSON values in custom fields, so the extras map should accept any JSON value.

Fix

Change the type of Header.extras from HashMap<String, String> to HashMap<String, serde_json::Value>.

Breaking change

Consumers that read from Header.extras directly now receive serde_json::Value instead of String. For string extras, .as_str().unwrap() (or pattern matching) is needed:

// Before
let v: &String = header.extras.get("custom").unwrap();

// After  
let v: &str = header.extras.get("custom").unwrap().as_str().unwrap();

Test plan

• Existing tests updated and passing
• New test decode_token_with_non_string_extra_header verifies integer header values are accepted
• Example and benchmark updated