refactor(connections): extract DatabaseType into a dependency-free TableProCoreTypes module

[datlechin]

Summary

Phase 1 (R-002) unblock — the lower-risk alternative to the full PluginKit dynamic-module unification.

The desktop app can't import TableProModels to share DatabaseType, because TableProModels depends on the SPM TableProPluginKit, which collides with the framework TableProPluginKit the app already links. But DatabaseType is import Foundation only. So instead of restructuring the plugin-loading architecture, this extracts DatabaseType into a new dependency-free SPM target TableProCoreTypes. The app can import that without pulling TableProPluginKit → no collision, and no change to the plugin-loading model.

• New leaf target/product TableProCoreTypes (no dependencies).
• DatabaseType.swift moved TableProModels → TableProCoreTypes.
• TableProModels (+ Query/Database/Sync) depend on TableProCoreTypes; TableProModels does @_exported import TableProCoreTypes, so every existing import TableProModels consumer — including mobile's 42 files and the package modules — sees DatabaseType unchanged. No per-file import churn.
• Drift gate's authoritative-DatabaseType path updated to the new location.

Risk Addressed

• R-002: the app can now share the single DatabaseType (desktop adoption / 8.2b is a separate follow-up). Avoids the high-risk dynamic-framework module unification entirely.

Verification

• swift build / swift test (host) — 62 tests pass.
• swift build --triple arm64-apple-ios17.0 — iOS-safe.
• scripts/audit-refactor-health.sh --check — drift gate green.
• swiftlint --strict clean on changed files.

Notes

• ABI bump: no. No plugin/app/framework target changes; no plugin-loading impact.
• @_exported import is the package-umbrella re-export pattern, used here to avoid churning all import TableProModels consumers.
• Next: the desktop can now adopt TableProCoreTypes.DatabaseType and drop its own struct (8.2b, ~120 files) — a separate PR.