Add fault-injection harness for ASIO subscription failures

[SeanTAllen]

Context

Three ASIO subscription failure paths exist in TCPConnection and cannot be exercised by the test suite:

• Connect timer subscription failure → _on_connection_failure(ConnectionFailedTimerError) (PR Handle ASIO_ERROR notifications from ponyc runtime #280)
• Idle timer subscription failure → _on_idle_timer_failure() (PR Add timer ASIO subscription failure callbacks #281)
• User timer subscription failure → _on_timer_failure() (PR Add timer ASIO subscription failure callbacks #281)

All three errored-flag branches in _event_notify are currently unreachable from tests because ASIO subscription failure is driven by kernel behavior (e.g., ENOMEM returned from kevent/epoll_ctl) and can't be injected portably from Pony code. PR #280 accepted this for the connect timer; PR #281 accepted it for the other two. Both PRs merged without coverage of these branches.

Why it matters

The failure helpers (_fire_connect_timer_error, _fire_idle_timer_failure, _fire_user_timer_failure) enforce a cancel-before-dispatch contract that lets application callbacks re-arm the timer without tripping idempotency or already-active guards. A regression that broke that ordering — or broke the state cleared by _cancel_*_timer — would not be caught by any existing test.

What a harness might look like

Open to ideas. Options worth considering:

• A build-time shim over PonyAsio.create_timer_event that can be instructed to deliver an errored ASIO notification for the next timer registration.
• A test-only FFI that sets a runtime flag consulted inside ponyc's ASIO layer.
• A separate "harness" Pony binary that uses ulimit/cgroups to induce real ENOMEM from the kernel (less precise but exercises the real code path).

Any harness that lands in lori should also be usable for future ASIO-error paths — this is not just about the three existing ones.

Out of scope

• Adding tests that depend on a harness that doesn't exist yet.
• Changing the production code paths to make them easier to test without a harness (that would invert the priority — the production code is the thing under test).