[kvlonge]

Why

SQLBuild writes ten warehouse state tables, and STATE_TABLE_NAMES in sqlbuild-core is meant to be their one list. Four names (microbatches, node results, audit results, janitor events) were still separate Python literals, and several Rust paths repeated table names as strings, so a rename could drift between the executor, the location sync and the janitor.

Changes

• The native module exports all ten state table names. Python imports the four that were literals from sqlbuild._native, and their Python definitions are deleted.
• Rust uses the sqlbuild-core constants in the warehouse metadata reads, the microbatch statements and the fingerprint and freshness ingest. The values are identical, so event IDs do not change.
• The microbatch table name no longer round-trips through the Python host table; its host entry is removed in every registry.
• The five SQL Server state-table builders share one helper instead of repeating the build, strip and wrap steps. Their SQL is byte-identical to before.

DuckShop edge case: not applicable. No project shape, data value or lifecycle changes; this only changes where existing names come from.

Verification

• make check-ci passes (ruff, ty, fensu, workspace clippy).
• 1,678 unit tests across adapters, executor, microbatches and native module paths, plus 318 state-table integration tests, including the served-location warehouse metadata sync.
• SQL Server builder output compared with origin/main for five builders and several database and schema values: identical.
• One independent review: no findings.