Unmanaged tables: tell ferro which tables it does not manage #486

Problem

A database often holds tables ferro should leave alone, and ferro has no way to be told so. Two shapes came up while resolving the adoption ticket (#467) on the in-house migrations map (#452):

(a) Tables no model declares. alembic_version, a hand-made audit_log, PostGIS's spatial_ref_sys. Today:

• Alembic autogenerate through the ferro bridge proposes op.drop_table("audit_log") for each one, and the user hand-writes an include_object hook in env.py to stop it.
• Auto-migrate is unaffected (migrate_destructive drops columns, never whole tables).
• The in-house migration system is unaffected by decision: its generator only sees declared models, and its drift check ignores tables absent from the snapshot (Adopting an existing database: baseline from auto-migrate or Alembic #467).

(b) Tables a model declares but ferro must not create or alter. A model over a legacy table owned by another service, or over a table another tool migrates (Django's managed = False). Ferro should query and save through the model and emit no DDL for it on any door: create pass, reconciliation pass, Alembic bridge, in-house generator.

Wanted

One way to say "ferro does not manage this table", covering both shapes:

# (a) config, per database alias — names or patterns
[tool.ferro.databases.default]
unmanaged_tables = ["audit_log", "spatial_*"]

# (b) on the model
class LegacyInvoice(Model):
    __ferro_managed__ = False
    id: int
    total: Decimal

Spellings above are placeholders, not decisions.

Open questions

• Where (a) lives. The in-house CLI's config ticket (Config and model discovery for the CLI #472) is deciding the config file and per-alias shape; this should reuse it.
• For (b): is an unmanaged model in a schema snapshot (so historical models can be built from it for data steps) while rendering no DDL? What does the drift check say about it? What happens to a foreign key from a managed table to an unmanaged one?
• Does every door honor one declaration (I-1: the decision of which tables are managed should be made in one place and consumed by each emitter)?

Origin

Maintainer request during the #467 grilling: users will have cases we cannot enumerate, and an explicit escape hatch for excluding tables is worth having. Not needed for the in-house migration spec to reach its destination, so it is filed on its own rather than as a ticket on that map.