Design SQLAlchemy 2.0 ORM models that avoid N+1 queries by construction

Design SQLAlchemy 2.0 ORM models for the domain below, using the modern declarative Mapped[...] typed style. The relationships need a deliberately chosen loading strategy per real access pattern — not the library default, which will produce an N+1 query problem the moment this is used in a list view.

DOMAIN
A blog: authors, posts, and comments on posts.

RELATIONSHIPS
An Author has many Posts; a Post has many Comments; a Comment belongs to one Post.

ACCESS PATTERNS
The main feed lists 20 posts at a time and always shows each post's comment count; an author's own dashboard shows their posts but comments are only loaded when a specific post is opened.

DATABASE
PostgreSQL 16

REQUIREMENTS
1. Use the SQLAlchemy 2.0 typed declarative style: class Model(Base) with Mapped[int] and mapped_column(...) annotations, not the legacy Column(...) class-attribute style — mixing the two styles in one codebase is a common source of confusing type-checker errors.
2. For every relationship in An Author has many Posts; a Post has many Comments; a Comment belongs to one Post., choose a loading strategy based on the actual access pattern in The main feed lists 20 posts at a time and always shows each post's comment count; an author's own dashboard shows their posts but comments are only loaded when a specific post is opened., not the SQLAlchemy default (lazy="select", which issues one extra query per parent row the first time the relationship is touched): selectinload for a one-to-many accessed in bulk (a single extra query for the whole batch, not one per row), joinedload for a many-to-one or one-to-one that's always needed alongside the parent, and lazy loading only where The main feed lists 20 posts at a time and always shows each post's comment count; an author's own dashboard shows their posts but comments are only loaded when a specific post is opened. confirms the relationship is genuinely rarely accessed and loading it eagerly would waste bandwidth on rows that never need it.
3. State explicitly, per relationship, which loading strategy you picked and why, referencing the specific access pattern that justifies it — a relationship configured without a stated reason is a relationship configured by accident.
4. Add appropriate indexes (index=True, or a composite Index(...) at the table level) on any column The main feed lists 20 posts at a time and always shows each post's comment count; an author's own dashboard shows their posts but comments are only loaded when a specific post is opened. shows being filtered or joined on frequently — a foreign key column that's never indexed turns a common filter into a full table scan as the table grows.
5. Use back_populates (not backref) for bidirectional relationships, and set cascade behavior explicitly (e.g. cascade="all, delete-orphan") rather than relying on the default, stating what happens to child rows when a parent is deleted.
6. If PostgreSQL 16 is Postgres-specific, use its native types where they fit (JSONB over a generic Text column for structured data, ARRAY where genuinely appropriate) rather than the lowest-common-denominator type that would also work on SQLite.
7. For any relationship configured with selectinload or joinedload here, confirm the query code that will actually use these models passes the right execution options (or that the relationship-level lazy= setting is sufficient on its own) — a relationship configured for eager loading still N+1s if the calling query re-specifies its own conflicting loader option, so state explicitly which side owns the final decision at query time.

OUTPUT FORMAT
1. The models, in dependency order.
2. A table: relationship, loading strategy chosen, and the access pattern that justifies it.
3. The indexes added, and what query each one is meant to speed up.
4. One sentence confirming whether the relationship-level default is sufficient on its own, or whether query-time loader options must also be set consistently.