Track broker-backed eventfd lifecycle and blocking semantics

[wdcui]

Follow-up from the broker message-layer cleanup work in PR #965. These issues appear to predate that PR (broker-backed eventfds were introduced in PR #880), so they should be handled in a focused lifecycle/blocking-semantics follow-up.

Issues to address

1. Broker object lifecycle for broker-backed eventfds

   • EventCounter stores a broker ObjectHandle, but there is no close/drop path that releases the broker object reference when the eventfd file description is closed.
   • Broker references are currently released when the whole broker session drops, so repeated eventfd create/close loops can exhaust broker reference limits for the lifetime of a broker connection.

2. Blocking vs nonblocking behavior for broker-backed eventfds

   • Broker-backed eventfds are created for nonblocking eventfds, but the file status can later be changed to blocking.
   • Blocking EventCounter::read/write waits on a local Pollee, but broker readiness/error notifications are not wired to wake waiters if the broker/control channel fails while a waiter is parked.

Possible directions

• Add an explicit broker object close lifecycle, likely a generic close-object operation routed through protocol/local/host/core and used by EventCounter/eventfd teardown.
• Define broker-backed eventfd blocking semantics. Until broker readiness/error notifications exist, either keep broker-backed eventfds effectively nonblocking-only or add the notification path needed to make blocking waits safe.