feat: add runtime_status and is_ready

[claudespice]

What

Adds two runtime health methods to SpiceClient:

• runtime_status() → Vec<ConnectionDetails>, wrapping GET /v1/status. One entry
  per runtime connection (http, flight, metrics, opentelemetry) with that
  component's endpoint and ComponentStatus.
• is_ready() → bool, wrapping GET /v1/ready.

Why

Neither endpoint was reachable from this SDK, so a Rust user waiting for a runtime to
come up — or diagnosing one that came up wrong — had to hand-roll reqwest calls
alongside the client they already had configured.

/v1/ready collapses the runtime to one boolean; /v1/status says which component
is not ready, which is the difference between "not up yet" and "Flight is failing".
Neither requires cluster mode or extra configuration, so both work on a default
spice run.

Two details worth a reviewer's eye:

• ComponentStatus has an Other(String) catch-all via #[serde(untagged)], so a
  status variant added by a future runtime deserializes instead of erroring.
• is_ready() returns Ok(false) for the runtime's 503 and reserves Err for a
  probe that could not be completed, so "not ready" and "could not ask" stay distinct.

Adding client() / base_url() / authorized() accessors to the crate-private
QueryHttpClient lets status.rs reuse the existing client and API-key handling
rather than standing up a second reqwest::Client. No public API change there.

Part of aligning runtime health/status coverage across the Spice SDKs.

Verification

• cargo build
• cargo test --lib — 182 passed, 0 failed (4 new)
• cargo test --doc — 23 passed, including the new README example
• cargo fmt --all --check
• cargo clippy --all-features — no new warnings
• Integration tests (tests/client_test.rs) — not run; they require a live runtime
  and SCP_SPICEAI_TPCH_API_KEY, neither available in this environment. They fail
  identically on unmodified trunk here.

[Copilot]

Pull request overview

Adds runtime health and per-component status support to the Spice.ai Rust SDK by exposing /v1/ready and /v1/status through SpiceClient, reusing the existing authenticated HTTP client.

Changes:

• Introduces status module with ComponentStatus, ConnectionDetails, and StatusError, plus internal QueryHttpClient helpers for /v1/status and /v1/ready.
• Adds SpiceClient::runtime_status() and SpiceClient::is_ready() methods that require http_url() configuration.
• Updates crate exports and README documentation/example to cover the new health APIs.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/status.rs	New runtime health/status types, errors, HTTP calls, and unit tests.
src/query.rs	Adds crate-private accessors so status.rs can reuse the configured/authenticated HTTP client.
src/lib.rs	Exposes the new status module and re-exports its public types.
src/client.rs	Adds SpiceClient convenience methods wrapping the new status/ready endpoints.
README.md	Documents and demonstrates runtime health/status usage.

[claudespice]

The 10 red Build and test jobs here are not this PR — every one of them dies in fixture setup, before a single test runs, and the cause is server-side.

ERROR Invalid argument: Failed to fetch Spicepod 'spiceai/quickstart' from spicerack.org: HTTP 503 Service Unavailable

Probed directly at 2026-07-29T11:28Z:

$ curl -sD - -H "Accept: application/zip" https://api.spicerack.org/v1/spicepods/spiceai/quickstart
HTTP/2 503
{"error":"IPFS fetch failed for spiceaiquickstartv0.1.08bb188f7b4106571cdec9b33f44963b04f928f7f and GitHub fallback not yet implemented"}

spiceai/tpch returns the same 503, while a pod that does not exist still returns a clean 404 {"error":"app not found"} — so name resolution is fine and only the artifact fetch is broken. spice add is failing for every published Spicepod, which also reds spicepy CI (#172, #173, and the #155 release PR) for the same reason.

Tracked in spiceai/spiceai#12116. Nothing to change on this branch — the remaining checks (Clippy on 1.93.1/beta/nightly, rustfmt) are green and the PR is approved, so a re-run should clear it once the registry recovers. I do not have write access here to trigger that re-run.

[claudespice]

Closing and reopening to re-trigger CI: all 10 Build and test legs on run 30316906401 (2026-07-28) failed on the same external cause — Failed to fetch Spicepod 'spiceai/quickstart' from spicerack.org: HTTP 503 Service Unavailable — not anything in this diff. The registry has since recovered (api.spicerack.org/v1/spicepods/spiceai/quickstart now returns 200), so a fresh run should be green. No code change.

[claudespice]

The reopen created a fresh run — 30647658880 — but it landed at action_required: fork PRs need a maintainer to approve the workflow run before it executes. One click on Approve and run should turn the board green now that the registry outage is over.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[claudespice]

The workflow-run approval I asked for on 2026-07-31 was granted — thank you. Run 30977349316 executed at 05:11Z today, so the old action_required park and the 2026-07-28 spicerack 503 diagnosis in my earlier comments are both superseded. Here is what the run actually shows.

All 10 red legs fail for one reason, and it is not this diff: the integration suite needs a repo secret that a fork PR never receives.

Every unit test passes on every platform. The only failure is --test client_test, and it fails identically everywhere:

Error: Query execution failed: Ipc error: Can't handshake
  code: 'The request does not have valid authentication credentials', message: "API key is required"

build.yml:181 supplies that credential as SCP_SPICEAI_TPCH_API_KEY: ${{ secrets.SCP_SPICEAI_TPCH_API_KEY }}. This PR's head is on a fork, and GitHub withholds repository secrets from cross-fork pull_request runs, so the variable arrives empty and the server rejects the handshake before any assertion in the test body runs.

Three independent checks that the diff is not implicated:

1. Trunk's own build for the same commit range is green — run 30971730156 — running these same tests with the secret.
2. tests/client_test.rs predates this branch; it was last modified in Add query bindings, dataset refresh, and GitHub release publishing flow #70.
3. Every unit test in the failing run passes, including all of status::tests, which is the code this PR adds.

This cannot be fixed from this branch — no change here can make a fork run see the secret.

Worth noting for whoever picks this up: GitHub currently reports this PR as MERGEABLE / UNSTABLE with an approving review, meaning the red legs are not required checks and the PR is merge-eligible as it stands. The durable fix, if the noise is unwanted, is to have client_test skip rather than panic when SCP_SPICEAI_TPCH_API_KEY is absent — but that is a test-harness change outside this PR's scope, so I have not made it here.

[claudespice]

Filed #88 to own the harness fix, so the permanent red on fork PRs has somewhere to be fixed rather than being re-diagnosed on each PR. Nothing about this branch changes — the ten Build and test legs stay red until client_test skips without the key.