Update explanation of contract enforcement (#4540)

## What are you changing in this pull request and why?
Rephrasing the explanation of when contracts might be supported but not
enforced. It's a _bold_ editorial choice to describe Postgres as a
legacy database; it's still current, but has different priorities.

Open to alternative phrasings but directionally this is where we should
be headed.

website/docs/docs/collaborate/govern/model-contracts.md

@@ -91,7 +91,7 @@ When building a model with a defined contract, dbt will do two things differentl
 Select the adapter-specific tab for more information on [constraint](/reference/resource-properties/constraints) support across platforms. Constraints fall into three categories based on support and platform enforcement:
 
 - **Supported and enforced** — The model won't build if it violates the constraint.
-- **Supported and not enforced** — The platform supports specifying the type of constraint, but a model can still build even if building the model violates the constraint. This constraint exists for metadata purposes only. This is common for modern cloud data warehouses and less common for legacy databases.
+- **Supported and not enforced** — The platform supports specifying the type of constraint, but a model can still build even if building the model violates the constraint. This constraint exists for metadata purposes only. This approach is more typical in cloud data warehouses than in transactional databases, where strict rule enforcement is more common.
 - **Not supported and not enforced** — You can't specify the type of constraint for the platform.