Heads-up: SchemaBot's core will stay code-host-agnostic for possible future non-GitHub support

## What

A heads-up for anyone following or building on SchemaBot: we intend to keep
SchemaBot's **core code-host-agnostic**.

SchemaBot is tightly integrated with GitHub today (PR comments, Check Runs,
branch protection, reviews/CODEOWNERS), but its core isn't fundamentally
GitHub-specific: discovering declarative schema, diffing against live databases,
linting unsafe changes, planning, coordinating applies, tracking progress, and
reconciling long-running work are all host-neutral. GitHub is the review and
merge-gating shell around that core.

We're posting this for **transparency**: this is a direction we've decided on,
not an open question. There's no rewrite planned and no near-term change — the
point is to set expectations now.

## What this means in practice

- The core (CLI, HTTP API, planning, engines, storage, reconciliation) stays
independent of any specific code host. The CLI and API already work without a
GitHub App.
- When GitHub integration code is touched, GitHub behavior gets isolated behind
a **capability boundary** rather than pushing new GitHub assumptions into core
types. The useful abstraction is a set of code-host capabilities, each of
which could have a provider adapter:
- repository content access (schema config + SQL files at an immutable ref)
- change/event ingestion
- human command surface (PR comments today; CLI is the universal fallback)
- merge gate / status publication (Check Runs today)
- reviews and approval state
- actor/team identity and authorization

## The hard part

Merge gating and the human workflow — the tier-0 safety path. Any future
alternative must preserve today's safety properties: a required gate on every
change, missing/uncertain status fails closed, status bound to the current
immutable head, and stale status can't satisfy a newer commit.

## Scope

- No rewrite for a hypothetical GitHub replacement.
- No new provider adapters in the near term.
- GitHub remains a first-class, fully supported integration.

This is a directional, informational issue and names no files, tests, or implementation entry points to inspect. There is no near-term change to make; the stated outcome is preserving a code-host-agnostic core and isolating GitHub behavior behind capability boundaries if future integration work begins.

Written by the indexing model from the issue text.