fix(ai): build the sensitive-word dictionary off the redis io threads (#7830) - #7844

Approved. The fallback path was the real offender and this fixes it properly.

Mono.just(AhoCorasick.of(words)) evaluated AhoCorasick.of eagerly at assembly time, on whatever thread assembled the chain — in onErrorResume that is the request thread, i.e. the Netty event loop. The redis path at least had subscribeOn(boundedElastic), but subscribeOn only moves the subscription upstream, so the map that builds the automaton still ran on the redis driver threads. Adding publishOn(boundedElastic) before the map is exactly the operator that moves the CPU-bound stage downstream, and Mono.fromCallable(...).subscribeOn(boundedElastic) is the correct way to defer a synchronous build.

Both new tests are discriminating rather than decorative, which is what makes this reviewable:

• testTheDictionaryIsBuiltOffTheRedisIoThreads drives the source on a dedicated simulated-redis-io parallel scheduler and asserts the build thread name does not start with that prefix. Without publishOn this test fails, because the map would run on the emitting thread — so it pins the actual defect.
• testTheRuleWordsAutomatonBuildIsDeferred asserts that assembling ruleWordsAutomaton(...) does not invoke AhoCorasick.of at all, then verifies the deferred build still works on subscription. That is precisely the eager-evaluation bug.

Three notes, none blocking:

1. The fallback Mono is cold and rebuilds per subscription. Mono.fromCallable re-executes on every subscribe where the old Mono.just reused one instance. In the current flow dictionary() is assembled per request and subscribed once, so the count is unchanged — and the result is still not cached in the fallback branch (only the redis branch calls cachedHandle). If the chain is ever retried or resubscribed, the automaton would be rebuilt each time off-loop. Worth a comment saying that is expected.

2. Two scheduler hops. subscribeOn(boundedElastic) plus publishOn(boundedElastic) means the subscription and the emission each cross a bounded-elastic queue. Reactive Redis is non-blocking, so subscribing from the caller thread is safe and the subscribeOn is arguably redundant now that publishOn guards the CPU stage. Not a correctness issue — just a hop worth dropping if this path ever shows up in profiles.

3. Visibility. redisAutomaton and ruleWordsAutomaton are package-private only so the test can reach them. private plus @VisibleForTesting, or exercising them through dictionary()/doExecute, would keep the plugin’s surface tighter. Minor.

CI has not reported on this branch yet — please confirm the workflow passes before merge.