Plan a major dependency upgrade so breaking changes get caught before your users find them

I need to upgrade SQLAlchemy from 1.4.51 to 2.0.29 and I want a real migration plan, not just 'bump the version and run the tests.'

DEPENDENCY AND VERSIONS
SQLAlchemy from 1.4.51 to 2.0.29

HOW WE USE IT
Used across ~30 model files with the legacy Query API and implicit autocommit sessions in a Flask app; no async usage

CHANGELOG OR RELEASE NOTES I HAVE
Migration guide states Query.get() is removed in favor of Session.get(), and autocommit mode is removed entirely in 2.0

TEST COVERAGE ON AFFECTED CODE
Model layer has maybe 40% coverage, mostly happy-path CRUD tests, nothing testing transaction/rollback behavior

Go through this as a plan, not a single answer dump:

Step 1 — From the changelog excerpt given, list every breaking change that plausibly touches the usage pattern I described. If the changelog excerpt doesn't mention something you'd expect to be relevant (e.g., a known common breaking pattern for this kind of library), say so and tell me what to go check in the full release notes rather than guessing at what it says.

Step 2 — For each breaking change identified, state the specific code pattern in our codebase that would need to change, based on the usage pattern described, and roughly how mechanical versus how risky that specific change is.

Step 3 — Given the test coverage state described, tell me plainly whether it's safe to make this upgrade with confidence, or whether specific tests should be written first before touching the dependency — name what those tests should assert, not just 'add more tests.'

Step 4 — Propose a migration order (e.g., which breaking changes to fix first, whether to do it in one PR or several) and a concrete rollback trigger: what specific signal after deploy would tell us this upgrade needs to be reverted, not a vague 'if something breaks.'

Do not invent specific breaking changes that aren't grounded in the changelog excerpt I gave you — if you're inferring a likely issue rather than reading it directly from the changelog, label it explicitly as an inference to verify against the real release notes.

OUTPUT FORMAT
1. Breaking changes table: change, why it matters to our usage, mechanical or risky, source (from changelog / inferred - verify).
2. Test coverage verdict and any tests to write first.
3. Migration order and PR-splitting recommendation.
4. The specific rollback trigger signal(s) to watch post-deploy.