feat(test): add Pact contract tests covering Namespace and Table APIs

[XuQianJin-Stars]

Summary

Introduce a consumer-driven contract testing suite for lance-namespace
based on the Pact framework pact-foundation. The suite covers both
Namespace and Table REST APIs (11 operations × success + 4xx error
scenarios) and verifies three language clients (Java / Python / Rust)
against the Spring Boot reference provider.

Problem

lance-namespace ships an OpenAPI spec plus auto-generated clients in Java,
Python and Rust, but so far there is no automated mechanism to guarantee
that:

1. Every client actually speaks the exact wire protocol the server implements.
2. Error responses (ErrorResponse) keep a consistent 4-field shape across
   languages and versions.
3. Breaking changes in request/response schemas are caught before they
   reach downstream consumers (pylance, rust callers, Spark/Ray integrations, …).

Typical symptoms without contract tests:

• A field rename on the server silently breaks a Python/Rust client at runtime.
• 4xx error bodies drift between languages (missing error, different casing,
  optional instance, etc.), making retries / user-facing messages inconsistent.
• Each client re-invents ad-hoc HTTP mocks, so regressions are only caught in
  integration environments.

Solution

A complete Pact-based contract test suite, plus a small contract-pack folder
that hosts the generated pact files, plus CI wiring that runs all three
consumer suites and the Spring Boot provider verification on every PR.

APIs under contract (success + 4xx for each)

Group	Operations
Namespace API	ListNamespaces, DescribeNamespace, CreateNamespace, DropNamespace, NamespaceExists
Table API	ListTables, DescribeTable, TableExists, DropTable, RegisterTable, DeregisterTable

Consumer interaction count

Client	File	Interactions
Java	NamespaceApiPactTest.java	22 (@Pact)
Python	test_namespace_api_pact.py	10
Python	test_table_api_pact.py	12
Rust	namespace_api_tests.rs	10
Rust	table_api_tests.rs	12
Total		66

Error body DSL

A reusable 4-field ErrorResponse shape (error, code, type, instance)
is enforced for every 4xx interaction, exposed as:

• Java: ErrorResponseDsl.java
• Python: error_response_dsl.py
• Rust: inline matchers under tests/

Provider verification

PactProviderTest boots an isolated PactTestApplication (Spring Boot,
pact profile, no external deps) and replays consumer pacts via
MockMvcTestTarget + @PactFolder, with provider states served by
PactStateController using InMemoryNamespaceFixtures.

CI pipeline (.github/workflows/pact.yml)

5 jobs, triggered on push and pull_request:

1. consumer-java — Consumer Contract Tests (Java Apache Client)
2. consumer-python — Consumer Contract Tests (Python urllib3 Client)
3. consumer-rust — Consumer Contract Tests (Rust reqwest Client)
4. provider-verify — Provider Verification Tests (Spring Boot Server),
   downloads pact-files-java/python/rust artifacts and replays them
5. can-i-deploy — Can I Deploy Check (main branch gate)

.pre-commit-config.yaml wires ci/pact_state_guard.sh so any new
@State("...") string must be whitelisted before commit.

Verification

• ✅ Java Consumer + Provider — 22 consumer pacts generated; provider
  verification replays all interactions, 0 failures
• ✅ Python Consumer — 22 tests pass locally (pact-python)
• ✅ Rust Consumer — 22 tests pass locally (pact_consumer + tokio)
• ✅ Sample pacts can be dropped under contract-pack/sample-pacts/ for
  offline provider verification without a live Pact Broker.

How to run locally

• Java consumer (generates pacts under java/lance-namespace-pact-tests/target/pacts)
  cd java && make test-pact-consumer
• Java provider verification (replays pacts via @PactFolder + MockMvcTestTarget)
  cd java && make test-pact-provider
• Python consumer
  cd python && make test-pact-tests
• Rust consumer
  cd rust && make test-pact-tests

close: #340
google doc: https://docs.google.com/document/d/1Wju0Ema10OkuDLs8tYzZ0xXqihX65k-OYabZbnc5NbI/edit?usp=sharing