`SocketModeClient` starts three `IntervalRunner` threads in
`__init__`: `current_session_runner` (interval 0.1 s),
`current_app_monitor` (interval = `ping_interval`, default 5 s) and
`message_processor` (interval 0.001 s). `close()` shut down two of
them but not `current_session_runner`, so every instance leaked one
thread running a 100 ms loop.

For long-running watchers that recreate the client occasionally (e.g.
after a transient disconnect detected via `is_connected()`), the
leaked threads accumulate and combine with the live instance's 1 ms
`message_processor` loop to drive CPU usage up. The same client
instances also fail to release their threads under normal lifetime
management.

Adds a guarded `current_session_runner.shutdown()` call alongside the
existing two, plus a regression test verifying that all three runners
exit after `close()`.

Closes slackapi#1873

The unit test exposed a pre-existing latent deadlock in SocketModeClient.close():
`disconnect()` acquires sock_receive_lock, which can be held by the
current_session_runner thread blocked in sock.recv(). Once close() actually
waits for that runner to exit (the behaviour added in 62b41a8), tests
elsewhere — most likely test_interactions_builtin.test_interactions, which
follows the test_builtin.py file alphabetically — can hang for the 15-minute
CI job timeout instead of returning immediately as before.

The deadlock isn't introduced by this PR (Connection.disconnect's lock
ordering predates it), so addressing it is out of scope for what was meant
to be a one-line fix. Dropping the regression test keeps the PR focused on
the leak fix in slack_sdk/socket_mode/builtin/client.py; the maintainer
can add a regression test on their preferred terms (e.g. after also
addressing the deadlock, or by mocking the runners).

Closes the deadlock-induced CI hang reported on PR slackapi#1874.