feat(namespace): preserve Retry-After metadata on ThrottlingError

Problem

A Lance Namespace REST server return a standard throttling response:

HTTP/1.1 429 Too Many Requests
Retry-After: 2

with the official Namespace error code 21 (THROTTLING).

However, the current REST Namespace client discards response headers while converting an HTTP response into a Namespace error. Callers only receive ThrottlingError with its message and error code; they cannot access Retry-After, the HTTP status, or other response metadata.

This prevents SDK and application layers from implementing server-directed retry, queuing, or throttling coordination.

Current behavior

The REST request path in rust/lance-namespace-impls/src/rest.rs receives a reqwest::Response, reads the error body, and maps its Namespace error code to an error type.

Response headers are not preserved during this conversion. Consequently, Python callers can catch:

except lance_namespace.errors.ThrottlingError as error:
    ...

but cannot determine whether:

• the server provided a retry delay;
• the throttling is temporary;
• the server returned a 429 without Retry-After, such as for a zero-quota or permanently restricted API key.

Expected behavior

ThrottlingError should optionally expose normalized retry metadata from the HTTP response.

Suggested cross-language shape:

ThrottlingError:
  retry_after: optional duration

For Python, this could be exposed as:

error.retry_after  # str | None

or add a common field to save response headers

LanceNamespaceError:
  response_headers: Option<Map<String, String>>

Start in rust/lance-namespace-impls/src/rest.rs, where reqwest::Response errors are converted into Namespace error types, and trace how ThrottlingError reaches Python callers. Done means callers can access optional normalized retry metadata for responses with and without Retry-After, while preserving the existing error code and message behavior.