feat: declarative rollback rules on #[transactional] (26.6.27)

[ancongui]

What

A Spring Boot parity increment (26.6.27): declarative transaction rollback rules on #[transactional].

Picked from a 16-area parity-gap analysis (the framework sits at ~84% overall Spring parity) as the best value-to-effort gap — the transaction runtime already supported per-error rollback decisions (transactional_with / transactional_with_on take a should_rollback(&E) -> bool), so only the macro surface was missing.

The feature

// Persist the audit row even when the domain rejects the charge, but still roll
// back on any infrastructure failure — @Transactional(noRollbackFor = …).
#[firefly::transactional(no_rollback_for = "BillingError::Rejected(_)")]
async fn charge(&self, req: Charge) -> Result<Receipt, BillingError> { … }

Spring names exception types; because Rust's Result already separates failure from success, the Firefly analog names an error pattern. By default every Err rolls back; then:

• no_rollback_for = "P" — Spring's @Transactional(noRollbackFor = …): an Err matching P commits instead of rolling back;
• rollback_only_for = "P": roll back only for errors matching P, committing the rest;
• with both, no_rollback_for wins on overlap.

Patterns allow A | B alternatives (no if guard). The generated predicate is matches!-based, so a pattern that doesn't fit the error type is a compile error. Composes with manager = "…" (the 2×2 routing across explicit-manager / process-global × rule / no-rule).

Fidelity note (why it's rollback_only_for, not rollback_for)

Spring's rollbackFor is additive — it widens the set of exceptions that roll back (checked exceptions don't, by default). Rust has no checked/unchecked split: every Err already rolls back, so an additive rule would be a no-op. The faithful rule here is therefore restrictive, and it is named rollback_only_for so a Spring migrant can't write rollback_for and silently invert their rollback behavior. Writing rollback_for is a friendly compile error pointing at the two correct rules.

Review

Adversarially reviewed before merge; the review caught and I fixed:

• the rollback_for naming footgun (→ rollback_only_for + intercept-with-error),
• the no-if-guard constraint (doc + parser),
• an untested process-global path (added a test).

Tests & docs

• A spy TransactionManager records the per-call commit-vs-rollback decision across all four cases (default / no_rollback_for / rollback_only_for / both-with-overlap) on both the explicit-manager and process-global paths — 5 tests, plus the existing trybuild UI tests.
• Docs: 07-persistence.md (with a "Not rollback_for" callout) + CHANGELOG.
• make ci green: 316 suites, 4489 tests, 0 failed.

First parity increment after the docs-correctness arc (#26–28). The roadmap's next-highest value lever is declarative @HttpExchange HTTP-interface clients.