perf(agent): scope seed data and enrich diff to speed up generation

Seed data was required for every previous-schema table, so the LLM spent
most of its time emitting throwaway seed rows that scale with schema size,
not migration size. Scope the requirement to the tables a migration
actually changes plus their FK parents, and give the model the context it
needs up front to avoid full-schema reads.

- schema: add changed_tables, foreign_key_parents, required_seed_tables,
  and definitions_for; refactor shared statement/name parsing helpers
- agent: require seed data only for the affected tables (+ FK parents),
  inline those tables' previous-schema definitions into the prompt, and
  make reading the full schemas optional
- diff: prefix each hunk with an '@@ <statement> @@' header so changes
  deep inside a CREATE TABLE show which object they belong to
- fix(output): make truncate char-boundary safe to avoid panics on
  multibyte characters in LLM output

feat: add --env flag and [env] config section

Pre-configure environment variables (e.g. AWS credentials for Bedrock)
via a repeatable --env KEY=VALUE flag and an [env] section in aim.toml.
Precedence, highest to lowest: --env flags, existing environment
variables, [env] config.

Variables are applied before the async runtime starts, since
std::env::set_var is only sound single-threaded. aim.toml is parsed once
into a RawConfig that drives both env setup and config resolution.

feat: add AWS Bedrock provider support

Add Bedrock as an LLM provider via the rig-bedrock companion crate.
Bedrock authenticates through the AWS credential chain rather than an
aim-managed API key, so it is treated as keyless like Ollama.

This also upgrades rig-core 0.33 -> 0.38 (aliased as `rig` to avoid
churn from the crate's lib rename), updating the provider dispatch for
the new Result-returning client constructors and porting the retry
history accumulation to the new prompt API.

feat(validation): add 'aim rules' subcommand to list enabled rules

List the resolved validation rules (built-ins minus disabled, plus custom
rules) with their levels. Also document the built-in rules in the README.

fix(verify): exclude dropped columns from down-migration data check

A column dropped by UP is re-added by DOWN with its DEFAULT, not its original
value, so requiring expected_after_down rows to retain the original value can
never pass. Exclude columns present in the previous schema but absent from the
desired schema from the down-direction row-existence predicates; row counts and
surviving columns are still verified.

fix: Probe Docker readiness over TCP (#4)

The postgres and mysql images run a temporary socket-only server
during first-time init, then restart with networking enabled. The
socket probes saw that bootstrap server, then raced the socket
vanishing mid-query, causing intermittent CI connection failures
(--tmpfs makes the data dir empty every run).

Probe over TCP so the bootstrap server is invisible and we proceed
only once the real server is listening. Also enable no_down in the
postgres example and drop its now-unneeded down migration.

feat(config): add no_down option to disable down migrations

Down migrations are easy to get wrong in ways that silently destroy
data on rollback (e.g. an UP that adds an enum value paired with a DOWN
that drops it). Add an optional no_down setting (aim.toml key + --no-down
flag) that generates, verifies, and writes only the UP migration.

- config: resolve no_down (default false) with the usual CLI override
- agent: prompt omits DOWN rules and expected_after_down; submit tool
  discards any down_sql; verify and seed-coverage skip the down checks
- formats: omit the down file/section when down_sql is empty (keyed off
  the data, so mixed histories work)
- validate: skip DOWN and UP+DOWN+UP per migration without down_sql,
  still validating the full UP chain (prints 'ok (up only)')

fix: reject literal/seed data inserts in generated migrations

Migrations could embed INSERT ... VALUES with seed rows to make the
UP/DOWN data-preservation checks pass, producing migrations that would
destroy real production data. Seed data must never appear in migration
SQL.

- Add a pre-verify guard that parses up_sql/down_sql and rejects any
  INSERT whose source introduces literal rows: VALUES clauses,
  constant-only SELECTs (no FROM), UNION branches of constants, and
  DEFAULT VALUES. INSERT ... SELECT that reads from a table is allowed.
- Feed violations back into the retry loop with corrective guidance.
- Rewrite the prompt DML rules: transform existing data only via
  UPDATE/DELETE or INSERT ... SELECT; never insert literal/sample rows.

chore: "waiting" -> "thinking"

feat: forbid manual intervention instructions in migrations (#2)

Migrations must be fully automated. Forbid comments or instructions
requiring manual steps; if data needs transforming, the LLM must
include the necessary DML directly. Also relax the DDL-only rule to
permit DML (UPDATE/INSERT/DELETE) for data transformations such as
mapping old enum values to new ones.