test(ui-common): cover buildStatusNotificationPayload 1.6/2.0.x branches (#1834)...

test(ui-common): cover buildStatusNotificationPayload 1.6/2.0.x branches (#1834) (#1902)

* test(ui-common): cover buildStatusNotificationPayload 1.6/2.0.x branches (#1834)

Adds a describe('buildStatusNotificationPayload') block matching the
existing payloadBuilders.test.ts style. Cases (9):

OCPP 1.6
- explicit errorCode: payload carries {connectorId, status, errorCode}
- errorCode omitted: payload omits errorCode (no NoError default)
- evseId pass-through with errorCode
- ocppVersion=undefined falls through to 1.6 shape
- unsupported version (e.g. '3.0') throws via assertOCPP16OrUndefined

OCPP 2.0.x
- VERSION_201 + evseId: {connectorId, connectorStatus, evseId}, no
  status / errorCode fields
- VERSION_20 without evseId: {connectorId, connectorStatus}
- errorCode option ignored (1.6-only field)

Cross-version
- same input, different ocppVersion: shapes differ in the documented
  way (status vs connectorStatus, errorCode/evseId presence)

Uses OCPP enum constants directly (OCPP16ChargePointStatus,
OCPP16ChargePointErrorCode, OCPP20ConnectorStatusEnumType,
OCPPVersion) per the OCPP enumeration-naming convention. Production
code in payloadBuilders.ts is unchanged.

* test(ui-common): exercise evseId-only path for OCPP 1.6 StatusNotification

Address review comment on #1902: the prior test 'should pass evseId
through for OCPP 1.6 when provided' passed both errorCode and evseId
together, so the evseId-only OCPP 1.6 branch was never independently
exercised. The errorCode-only path is already covered by the case
'should build OCPP 1.6 payload with status and explicit errorCode',
and the combined case is trivial composition of the two via the
spread syntax in the function body.

Test renamed to 'should pass evseId through for OCPP 1.6 without
errorCode' and now only passes options.evseId, asserting errorCode is
absent from the resulting payload.