Consider divorcing `tokio`

I am not satisfied with the current state of `Arc` spams and hacks to adhere to the `'static` bounds imposed by `tokio`. It is also currently one of our more heavier dependencies:

```
File .text Size Crate
2.4% 13.5% 485.0KiB std
1.2% 6.9% 248.2KiB russh
1.1% 6.5% 233.2KiB config
1.1% 6.2% 221.9KiB ssh_portfolio
1.0% 5.8% 207.7KiB regex_syntax
1.0% 5.4% 194.9KiB clap_builder
0.9% 5.0% 178.3KiB internal_russh_forked_ssh_key
0.6% 3.5% 126.7KiB regex_automata
0.6% 3.4% 121.6KiB tokio
0.5% 2.7% 96.2KiB backtrace
0.4% 2.5% 90.4KiB yaml_rust2
0.4% 2.4% 87.3KiB hyper
0.4% 2.4% 84.6KiB num_bigint_dig
0.4% 2.2% 79.9KiB tracing_subscriber
0.3% 2.0% 70.5KiB axum
0.3% 1.6% 58.5KiB json5
0.3% 1.5% 54.2KiB toml
0.3% 1.4% 51.5KiB ratatui
0.2% 1.3% 47.6KiB gimli
0.2% 1.2% 44.7KiB p521
```

Migrating away would likely be quite challenging, as we rely heavily on tokio and its ecosystem throughout the codebase. We would also need to find compatibility layers or alternatives to our tokio-based dependencies that are not async runtime-agnostic.

Start by inventorying the codebase's tokio usage and the tokio-based dependencies mentioned in the issue. Compare possible runtime-agnostic compatibility layers or alternatives, then assess whether the Arc-related workarounds and dependency-size concerns can be addressed without breaking the SSH server or TUI application.

Written by the indexing model from the issue text.