Feat/match tenant reference

[TravelCurry02]

Contributor checklist

Leave anything that you believe does not apply unchecked.

• I accept the AI Policy, or AI was not used in the creation of this PR.
• Bug fixes include regression tests
• Chores
• Documentation changes
• Features include unit/acceptance tests
• Refactoring
• Update dependencies

Summary

• Added optional match_tenant? on postgres.references.reference (default false) so attribute-multitenant foreign keys can require matching tenants.
• When enabled, the migration generator includes with: [tenant: tenant], match: :full on primary-key references, which blocks cross-tenant relationships at the database.
• Non-PK attribute-tenant references still get tenant matching automatically (existing behavior).
• Addresses Relationships are able to cross tenants with attribute strategy #192

Why

Ash used to always add the tenant column to composite FKs. That broke Postgres when the destination was a primary key (#144), because (id, tenant) needs a unique index covering those columns. The earlier fix skipped the tenant column for PK references, which unblocked migrations but allowed cross-tenant rows to be inserted.

Changes

• lib/reference.ex — new match_tenant? option
• lib/migration_generator/operation.ex — include tenant matching on PK refs when the option is on
• lib/migration_generator/migration_generator.ex — pass the option through snapshots
• .formatter.exs — register match_tenant? for Spark formatter
• documentation/dsls/DSL-AshPostgres.DataLayer.md — document the option
• test/migration_generator_test.exs — test that match_tenant?: true generates with: [org_id: :org_id], match: :full

Usage

postgres do
  references do
    reference :user, match_tenant?: true
  end
end

Notes

Enabling this on a PK reference may still require a unique index covering (tenant, id) on the destination (same Postgres constraint as #144). Happy to follow up if maintainers want that generated automatically.