fix(i2c_master): yield from ISR when no matching device is found (IDFGH-17648)

[DatanoiseTV]

Summary

i2c_master_isr_handler_default() may set HPTaskAwoken to pdTRUE
through the FromISR primitives it calls earlier in the handler:

• xQueueSendFromISR(i2c_master->event_queue, ...) near the top of the
  handler when an event needs to be reported,
• xSemaphoreTakeFromISR(i2c_master->bus_lock_mux, ...) /
  xSemaphoreGiveFromISR(i2c_master->bus_lock_mux, ...) around the
  device-list lookup in the async_trans branch.

When the device-list lookup at lines 822-828 fails to find a device
matching i2c_trans.device_address, the handler took an early
return; at line 830, skipping the portYIELD_FROM_ISR() at the
bottom of the function. A higher-priority task waiting on the bus
lock or on the event queue would therefore have to wait for the next
scheduler tick instead of being preempted into immediately, inflating
worst-case event latency on this path.

Fix

Replace the early return with a goto out to the existing yield
check at the end of the ISR. Behavior is otherwise unchanged.

Reproduction

The path is exercised whenever an interrupt fires for a transaction
whose configured device is no longer present in the device list (for
example after i2c_master_bus_rm_device() removes a device while a
transaction is in flight, or under fault conditions where the address
in i2c_trans doesn't match any registered handle). The fix is a
correctness improvement on a latency-critical path; behavior is
verifiable by tracing the out: path with an instrumented build.

Test plan

• Build passes with the fix on top of master.
• Existing components/esp_driver_i2c/test_apps/i2c_test_apps
  regression suite continues to pass on supported targets.

[CLAassistant]

All committers have signed the CLA.

[suda-morris]

sha=0f0d7a758ee3f591515e5cd9173a78236490452b