fix(ssr-runtime): coerce className to string for non-string values

[nikhil6393]

Summary

Fixes #5093
In browsers, setting element.className to a non-string value (e.g. undefined, null, 0, false) coerces it to its string representation. The SSR v2 runtime (@lwc/ssr-runtime) was storing the raw value without coercion, diverging from browser behaviour.

Root cause: The className setter in LightningElement (SSR v2) stored newVal directly into #props.class and #attrs.class without calling String().

Fix

Add String() coercion inside the className setter in packages/@lwc/ssr-runtime/src/lightning-element.ts:

set className(newVal: any) {
    // Coerce to string to match browser behaviour:
    // e.g. `element.className = undefined` -> className is "undefined"
    const strVal = String(newVal);
    this.#props.class = strVal;
    this.#attrs.class = strVal;
    mutationTracker.add(this, 'class');
}

Tests

Added unit tests in packages/@lwc/ssr-runtime/src/__tests__/lightning-element.spec.ts covering:

• undefined -> "undefined"
• • null -> "null"
• • 0 -> "0"
• • false -> "false"
• • numeric values
• • objects with toString()