Add the transactions module, and move the migration project under migration-behavior/

The repository now aggregates two independent modules. migration-behavior/ is the
original project, moved unchanged; it stays on Spring Boot 4.0.6 / JDK 21 because
that is what the four published migration articles were verified against, and
upgrading it would silently invalidate output they quote. The article-tagged trees
are untouched, so links into a tag are unaffected.

transactions/  Companion code for "@Transactional in Spring: Propagation, Isolation,
and the Six Ways It Silently Does Nothing". Spring Boot 4.1.1 / JDK 25.

Every row of the propagation matrix is produced by calling the method and asking the
transaction manager what it did. The transaction NAME is the exhibit: a scope that
joined reports its caller's name, a scope that started its own reports its own.

Three things the transcripts settle:

  - Propagation.NESTED cannot be used with JpaTransactionManager. It fails twice,
    with two different messages, the second of which blames your JPA provider. The
    savepoint manager comes from the object the JpaDialect returns when it begins the
    transaction, and Hibernate's does not implement one. It works on
    DataSourceTransactionManager, because a savepoint is a JDBC concept -- shown
    working there rather than only failing here.
  - Catching a REQUIRED inner failure does not save the transaction. The inner scope
    has already marked it rollback-only, so the commit throws
    UnexpectedRollbackException from a place with no connection to the cause.
  - A checked exception commits, and so does a swallowed one. Those two do not merely
    fail to start a transaction; they commit work the code was abandoning.

19 contract tests, six captured transcripts, all regenerated by scripts/run-all.sh.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gip4srpzMwjgoba6uEfbr5

transactions/docs/03-rollback.md

@@ -0,0 +1,88 @@
+[← Propagation](02-propagation.md) · [Index](../README.md) · [NESTED and JPA →](04-nested-and-jpa.md)
+
+# 3. Rollback, and the exception that appears from nowhere
+
+Transcript: [`02-rollback.txt`](output/02-rollback.txt).
+
+## Does the inner work survive the caller's rollback?
+
+```
+REQUIRED inner, outer rolls back        rows: 0   inner work rolled back
+REQUIRES_NEW inner, outer rolls back    rows: 1   inner work SURVIVED
+```
+
+That is the entire reason `REQUIRES_NEW` exists. Audit rows, outbox entries and "we tried and
+it failed" records need to survive the failure that produced them, and only an independent
+physical transaction can do that.
+
+## `UnexpectedRollbackException`
+
+The one worth understanding before it happens at 3am:
+
+```
+REQUIRED inner throws, outer catches it
+    outcome : UnexpectedRollbackException
+    message : Transaction silently rolled back because it has been marked as rollback-only
+    rows    : 0
+```
+
+The sequence:
+
+1. Outer method starts a transaction and calls an inner `REQUIRED` method.
+2. The inner method throws. Its interceptor sees a `RuntimeException` — but it is *participating*
+   in the caller's transaction, so it cannot roll back on its own. It sets **rollback-only** on
+   the shared transaction and rethrows.
+3. The outer method catches the exception and returns normally, believing it handled the
+   failure.
+4. The outer interceptor tries to commit. The transaction is marked rollback-only, so it rolls
+   back and throws `UnexpectedRollbackException`.
+
+Catching the exception did not save the work. It moved the failure to the commit boundary,
+where the stack trace has nothing to do with the original cause.
+
+With `REQUIRES_NEW`, the same code behaves the way it reads: the inner transaction rolled back
+independently and the caller's catch worked.
+
+**If you must catch and continue, the inner call has to be `REQUIRES_NEW`.** No amount of
+exception handling in the caller fixes a `REQUIRED` inner scope, because the damage is a flag
+set on a transaction the caller shares.
+
+## What triggers a rollback
+
+By default: `RuntimeException` and `Error`. **Not** checked exceptions.
+
+```java
+@Transactional(rollbackFor = Exception.class)          // roll back on checked too
+@Transactional(noRollbackFor = NotFoundException.class) // and the reverse
+```
+
+The default comes from EJB and surprises almost everyone the first time. A method that declares
+`throws IOException` and throws it will **commit** — see [chapter 5](05-six-silent-failures.md),
+failure 3.
+
+## Changing the default globally, new in Spring 7
+
+`@EnableTransactionManagement` gained a `rollbackOn()` attribute taking a new `RollbackOn` enum:
+
+```java
+@EnableTransactionManagement(rollbackOn = RollbackOn.ALL_EXCEPTIONS)
+```
+
+Two constants: `RUNTIME_EXCEPTIONS` (the historical behaviour) and `ALL_EXCEPTIONS`.
+
+Note where it lives. Disassembling `org.springframework.transaction.annotation.Transactional`
+in spring-tx 7.0.9 shows twelve attributes and no `rollbackOn` among them, so this is a
+configuration-level switch rather than a per-method one. Per-method control is still
+`rollbackFor` / `noRollbackFor`.
+
+If checked exceptions committing has bitten you before, this is the switch to flip once rather
+than the annotation to remember on every method.
+
+## Marking rollback-only yourself
+
+```java
+TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
+```
+
+Honest when you want to abandon the transaction without throwing — but the caller then gets
+`UnexpectedRollbackException` at commit, so make sure that is what you want.