Ignore closed-terminal log errors in Puma plugin shutdown

[afurm]

Summary

Fixes #737.

When the Puma plugin monitor detects that Puma has gone away, it logs a shutdown message before sending INT to stop Solid Queue. If the controlling terminal has already been closed, Puma's log writer can raise Errno::EIO, preventing the shutdown signal from being sent.

This makes plugin logging tolerate Errno::EIO so shutdown can continue.

Changes

• Rescue Errno::EIO from the Puma plugin log helper
• Add a unit test proving the monitor still sends the shutdown signal when logging fails

Validation

• TARGET_DB=sqlite RBENV_VERSION=3.4.4 bundle _2.5.16_ exec ruby -Itest test/unit/puma_plugin_test.rb
• TARGET_DB=sqlite RBENV_VERSION=3.4.4 bundle exec ruby -Itest test/integration/puma/plugin_async_test.rb
• TARGET_DB=sqlite RBENV_VERSION=3.4.4 bundle exec ruby -Itest test/integration/puma/plugin_fork_test.rb
• RBENV_VERSION=3.4.4 bundle exec rubocop lib/puma/plugin/solid_queue.rb test/unit/puma_plugin_test.rb

[afurm]

I saw the Tests (3.4, sqlite, rails_8_1) job fail once in RecurringTasksTest#test_enqueue_and_process_periodic_tasks with one recurring StoreResultJob ending as "completed" instead of the configured "custom_status".

I tried to reproduce the exact matrix and seed locally:

BUNDLE_GEMFILE=$PWD/gemfiles/rails_8_1.gemfile TARGET_DB=sqlite RBENV_VERSION=3.4.4 bundle exec ruby -Itest test/integration/recurring_tasks_test.rb --seed 33880
BUNDLE_GEMFILE=$PWD/gemfiles/rails_8_1.gemfile TARGET_DB=sqlite RBENV_VERSION=3.4.4 bundle exec bin/rails test --seed 33880

Both passed locally. The full suite result was 230 runs, 1304 assertions, 0 failures, 2 skips.

This looks unrelated to this PR’s Puma plugin logging change, so I’m treating it as a likely flaky/order-sensitive recurring scheduler failure and will rerun CI.