fix(archive): make probe() async; remove block_on inside tokio runtime

[bravo1goingdark]

Summary

`Archiver::probe()` was synchronous but called `Handle::current().block_on()` on an async S3 head request. The startup path that invokes it (`Server::run_inner`) is async — sitting inside the tokio runtime created in `keplor-cli/main.rs:run_server`. tokio explicitly disallows nested `block_on`, so anyone enabling `--features s3` and configuring `[archive]` hits this immediately on startup:

```
thread 'main' panicked at crates/keplor-store/src/archive.rs:74:49:
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
```

This is the first time the s3 feature shipped live, so the bug had no production exposure before now.

Fix

• `Archiver::probe()` → async fn, awaits `self.client.head` directly.
• Single caller in `keplor-server/src/server.rs:304` updated to `.await` it.

3-line change.

Verified

End-to-end against a real Cloudflare R2 bucket — startup log:

```
{"level":"INFO","message":"event archival configured — S3 connectivity verified","bucket":"keplor-log","archive_after_hours":720,"archive_threshold_mb":15000,"interval_secs":3600}
```

`/health` 200, no panic.

Test plan

• cargo build --release -p keplor-cli --features s3
• Live startup against R2 bucket with valid credentials → "S3 connectivity verified" message appears
• Live startup against bogus credentials should now fail-and-disable archival cleanly (probe returns Err, archival disabled, server keeps running)