credentials.rs reads two optional-looking fields with unwrap_or("") #55

The code

crates/token/src/credentials.rs:353-364, inside the loop that finds a user's
service info:

let operator = args
    .get("operator")
    .and_then(|v| v.as_str())
    .unwrap_or("")
    .to_string();

let dso = args
    .get("dso")
    .and_then(|v| v.as_str())
    .unwrap_or("")
    .to_string();

A missing operator or dso, or one that is not a string, yields an empty
string. The function returns Ok, and the caller receives a UserServiceInfo
with a blank party where a party belongs.

The field above them is stricter. user at line 348 uses continue when it is
missing, so the entry is skipped rather than returned blank.

Why an empty party is worse than an error here

An empty string is not an obviously wrong party. It flows into later calls as a
party id and compares unequal to everything, so a filter returns nothing and the
caller reads an empty result rather than a failure.

Suggested fix

Return an error naming the field, the way the user arm already refuses to
continue without one:

.ok_or_else(|| format!("`operator` missing or not a string in {template_id}"))?

Decide per field whether it is genuinely required. If either is legitimately
absent in some responses, type it Option<String> rather than blanking it, so a
caller can tell absent from empty.

Where this came from

cbtc-lib issue #50 catalogued seven parsers using as_str().unwrap_or("") and
named src/credentials.rs among them. cbtc-lib 0.7.0 moved that module into
this crate, and its own remaining parsers were retyped onto typed created
events, so no instance survives there. These two lines are the instance that
moved.

crates/token/src/active_contracts.rs:36 also uses the pattern, and is not this
defect: it compares a metadata value, so a missing key correctly fails to match.