logging: `logging.console` precedence over logback.xml is undocumented, and `report: 'warn' is the wrong `printEnabled` replacement (empties the gatling replay)

Follow-up to #2998 (and #2937), from the same customer's feedback on 2.1.2. Three things were reported; two are docs / advice defects, one is not a defect but exposed a wrong migration hint. Verified against HEAD, whose replay and print paths are unchanged since v2.1.2.

1. logging.console overwrites logback.xml per-category levels — by design, but the docs hide it

configure logging = { console: X } (karate-config.js, --log-console, karate-pom.json) calls LogContext.setRuntimeLogLevel, which sets Logback level X on karate, every karate.* category and io.karatelabs, replacing whatever the user's logback.xml pinned for those names, snapshotted and restored per scenario. That is the fix for #2917 and stays. What is missing:

• No page states the precedence rule or the escape hatch: omit console and Karate never touches Logback levels — logback.xml then governs entirely. The docs table lists console with a "default info", which reads as a live default; it is only the value karate.get('config') reports, nothing applies it.
• logging.mdx says the override lasts "for the duration of the run"; it is per scenario.
• performance-testing.mdx sets console: 'warn' in the sample karate-config.js and, thirteen lines later, gives a logback.xml recipe (karate.scenario INFO, karate.http TRACE) that the console line silently defeats. The customer hit exactly this: "setting logging.console to any value completely overrides any loglevel specific setting in logback.xml".

2. report: 'warn' is the documented replacement for printEnabled = false — it is wrong

print / karate.log() go to SLF4J karate.scenario at INFO unconditionally (LogContext.LogWriter); only the report-buffer append is gated by logging.report. So report: 'warn':

• does not stop prints reaching the console, and
• empties the Gatling log replay (HTTP blocks and prints enter the buffer at INFO), which then logs its "captured no output … configure logging = { report: 'info' }" hint.

That hint is why the customer concluded "logging.report: 'info' must be set to enable the log replayer". It is not: the default report threshold is DEBUG and replay is enabled solely by karateProtocol().logReplay(...). Wrong advice lives in the printEnabled deprecation warning in KarateConfig, docs/MIGRATION_GUIDE.md, karate-docs migration page, logging.mdx (the mask section), and the performance-testing.mdx troubleshooting row "Log replay produces nothing → set logging.report to info".

The correct v2 equivalent of printEnabled = false is the Logback level of karate.scenario (or console: 'warn' to quiet all karate output).

3. "The replayer outputs only HTTP requests and responses" — not reproducible

A new test (LogReplayerOutputTest) runs a feature with print, karate.log(), karate.logger.info() and one HTTP call under logReplay(FAILED): all three markers ride the single replay event alongside the request/response block. The customer's actual wish — prints suppressed from the live log and visible only in the replay of a failed feature — already works: pin karate.scenario (or all karate.* and io.karatelabs) to ERROR in logback.xml and enable logReplay; the replay is emitted on io.karatelabs.gatling.LogReplayer at ERROR, so it clears the pin. Covered by printIsSilencedLiveButStillReachesTheReplay. Not documented anywhere; will be, as the Gatling "prints only on failure" recipe.

Work

• KarateConfig: printEnabled deprecation message points at karate.scenario / console, not report.
• LogReplayer: reword the empty-replay hint so it reads as "something raised report above INFO", not "set report: 'info' to enable".
• Tests: keep LogReplayerOutputTest (replay carries print/karate.log/karate.logger; prints silenced live but replayed; no report needed; report: 'warn' is what empties it).
• docs/MIGRATION_GUIDE.md, docs/DESIGN.md, docs/GATLING.md: precedence rule, corrected printEnabled row, replay recipe.
• karate-docs: logging.mdx, performance-testing.mdx, migration-from-v1.mdx, configuration.mdx — same corrections.