What's changed?

FixStringFormatExpressions now skips its arg-trimming step entirely
whenever zero % conversion specifiers matched in the format string —
not just when the string happens to contain {} tokens. Previously it
deleted every trailing argument in that case, treating them as dead
code. Also fixes a related counting bug: %n and %% don't consume
an argument in java.util.Formatter, but the existing loop counted
them as if they did.

What's your motivation?

Deleting arguments from a format string with zero real specifiers is
only safe if you're sure they're actually unused. That's not a safe
assumption when the string uses a different templating convention
entirely — most commonly SLF4J-style {} placeholders mistakenly used
with String#format instead of a logger:

  String.format("expect {}, actual {}", original, shadow)                                                                                                                                                
  → String.format("expect {}, actual {}")   // args silently dropped                                                                                                                                     

The calling code already had a bug (wrong placeholder syntax for
String#format), but this recipe made it worse: it doesn't fix the
real problem, and it deletes the evidence (the arguments) that would
help a reviewer notice something's off. Real-world case that surfaced
this: a shadow-traffic mismatch reporter whose diagnostic messages all
degraded to the literal string "expect {}, actual {}", with no
values, after this recipe ran on it.

Anything in particular you'd like reviewers to focus on?

Two things beyond the headline fix:

1. The %n/%% counting fix — without it, a format string mixing
   %n (e.g. from this recipe's own newline replacement) with a
   zero-specifier string would be miscounted as having a real
   specifier on a later recipe cycle, silently defeating the main
   fix. Caught by the newlineStillReplacedWhenArgsAreNotStripped
   test.
2. As a side effect, this also resolves a separate latent bug in the
   .formatted() path: the trim step's i == 0 keep-clause assumed
   index 0 of the argument list is always the format string, true for
   String.format(fmt, args...) but false for
   "fmt".formatted(args...) (where index 0 is the first real
   argument) — that previously forced one argument to survive even
   when zero should remain. That branch is only reachable when zero
   specifiers matched, which is now always skipped, so no separate
   fix was needed. Covered by
   doNotStripArgsWithNoSpecifiersEvenWithoutPlaceholders.

Anyone you would like to review specifically?

No specific request — open to whoever's around.

Have you considered any alternatives or workarounds?

Yes, two:

• A narrower fix that only special-cased {}-style tokens specifically
  (detect SLF4J placeholder syntax via a dedicated regex), rather than
  bailing out on any zero-specifier case. Went with the broader
  version instead: it's simpler (no new pattern needed), and it's
  robust to other broken-templating conventions we haven't thought of
  (e.g. MessageFormat-style {0}), not just SLF4J. The tradeoff is
  it also stops trimming genuinely dead args when there's no
  placeholder-like syntax at all (covered by
  doNotStripArgsWithNoSpecifiersEvenWithoutPlaceholders) — a
  reasonable cost for not having to guess.
• Disabling the whole recipe as a workaround downstream, which is what
  prompted finding this in the first place. Fixing it here is
  obviously preferable.

Any additional context

Full module suite: 2145 tests, 0 regressions from this change (1
pre-existing failure in
AllBranchesIdenticalTest.collapseIdenticalBranchesPython, a local
Python-toolchain environment issue unrelated to this change).

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files