FFI: `FFI_SchemaProvider` missing `table_type` cheap-path

## Gap

`FFI_SchemaProvider` in `datafusion/ffi/src/schema_provider.rs` does not plumb `SchemaProvider::table_type`. Consumer-side `ForeignSchemaProvider` falls back to the trait default, which calls `table()` — forcing a full async lookup just to answer a question producers can usually answer cheaply.

## Missing method

- `table_type` (async, defaulted on the trait)

## Why it matters

**Severity: important.** Queries against `information_schema.tables` iterate over every table in every schema, asking only for its type. Without the cheap-path, every probe pays an unnecessary FFI hop into `table()` plus whatever the producer does to materialize a `TableProvider`. Producers that override `table_type` to avoid this work see their optimization silently discarded.

## Adjacent observation (not part of this issue)

`owner_name` is currently exposed as a static `FFI_Option` snapshot field rather than a function pointer. That works for the common case but cannot reflect dynamic owner changes. Worth a separate discussion if a producer needs the dynamic behavior; this issue is only about `table_type`.

## Implementation notes

- Plumb `table_type` as `unsafe extern \"C\" fn(...) -> FfiFuture>>`; wrapper body calls `inner.table_type(name).await`.
- Layout change → `api change` label, target `main` only, no back-port to `branch-`.
- Add unit tests (local-bypass + `mock_foreign_marker_id` forced-foreign) **and** integration test under `datafusion/ffi/tests/ffi_catalog*.rs` covering both the override path and the consumer-side fallback.

---

Generated from `datafusion-ffi` skill audit. See `.ai/skills/datafusion-ffi/SKILL.md` §"Method coverage" and §"Known gaps to close" (originated in PR #22327). If a PR addressing this finds the omission to be a false positive (e.g., a documented reason to keep the async-default path), please also propose an update to the `datafusion-ffi` skill so future audits do not re-flag it.