get_state_array() early return bypasses event_map handling — status entities using conditional events are never polled

The feature I requested in OBS-3979 has regressed.

Affects: 
Any status type defined with event_map instead of a flat event. Concretely ENERGY-OBJECT-MIB::eoPowerOperState (type PowerStateIeee), added under OBS-3979.

Symptom: 
Outlet status entities stopped updating in mid-2023. status_polled frozen while every other entity on the device polls normally; values years stale; graphs error with rrd_fetch_r failed … No such file or directory because the RRDs were never created.

Checking (snmp) Outlet 4 
Unresolved state for status 'Outlet 4' (type: PowerStateIeee, value: 259), skipping.

Everything upstream is correct. The device returns 259. includes/definitions/mibs/rfc.inc.php:494 declares 'oid_map' => 'eoPowerAdminState'; discovery reads it (status.inc.php:426) and stores status_map = 'ieee1621On' in the DB; the poller passes it into get_state_array() as $event_map (status.inc.php:781).

Root cause — includes/entities/status.inc.php: 
The early return at ~126–136 (the get_states_definition() fast path) reads $state_def[$value]['event']. For event_map types that key does not exist, so event is NULL, the caller's isset($state_array['event']) fails at 782, and the entity is skipped — before both the DB write and RRD creation, which is why no RRD ever gets made.

The correct event_map handling exists at lines 200–206 but is unreachable, shadowed by that early return.

Suggested fix: 
only take the fast path when a flat event is actually present, e.g. guard it with isset($state_def[$numeric_value]['event']) so event_map types fall through to the existing resolver at 200–206.

Impact: 
silent — discovery creates entities with correct values, so the UI shows plausible data indefinitely while the poller discards every subsequent reading. Affects any PDU using ENERGY-OBJECT-MIB.