Closes #3506

Problem

The Bedrock embedding compute path (rust/lancedb/src/embeddings/bedrock.rs) panics instead of returning a typed error in several places:

• serde_json::to_vec(&request_body).unwrap(): request serialization.
• block_in_place(...).unwrap(): the AWS invoke_model send result; any API error terminates the worker instead of propagating.
• v.as_f64().unwrap() as f32: panics on non-numeric values in the returned embedding array.
• Handle::current() + block_in_place assume a multi-threaded Tokio runtime and panic when that assumption does not hold (no runtime, or a current-thread runtime).

Malformed payloads, non-numeric embedding values, or an incompatible runtime should surface as typed errors and never panic.

Fix

• Serialize the request body before the blocking section so a serialization failure returns Error::Runtime via ?.
• Map the invoke_model send error to Error::Runtime instead of unwrap.
• Add a json_array_to_f32 helper that converts the response array to Vec<f32>, returning Error::Runtime for a missing/non-array field or a non-numeric element (used by both the Titan and Cohere paths).
• Add current_multi_thread_handle() (Handle::try_current() + a RuntimeFlavor::CurrentThread guard) so an absent or incompatible runtime returns a typed error rather than panicking in block_in_place.

Scope note: the sibling openai.rs provider uses the same block_in_place + block_on bridge, so the bridge pattern itself is kept; this change only removes the panic paths that are specific to the Bedrock provider.

Testing

Added 6 unit tests (no AWS credentials required):

• json_array_to_f32: valid numbers, non-array payload, and non-numeric element.
• current_multi_thread_handle: errors with no runtime, errors on a current-thread runtime, and succeeds on a multi-threaded runtime.

All pass; cargo fmt and cargo clippy clean. Build/test with --features bedrock,lance/protoc.