IntentIQ Identity module: server-side identity resolution

[Bengo7918]

🔧 Type of changes

• new bid adapter
• bid adapter update
• new feature
• new analytics adapter
• new module
• module update
• bugfix
• documentation
• configuration
• dependency update
• tech debt (test coverage, refactorings, etc.)

✨ What's the context?

Adds the intentiq-identity module — a server-side identity-resolution hook. At the
processed-auction-request stage it calls the IntentIQ Bid Enhancement S2S API and merges the
resolved IDs into user.eids before the request is sent to bidders. Optionally, at the
auction-response stage it reports winning bids as impressions to a reporting endpoint.

The module includes an optional two-layer cache (Caffeine L1 + a pluggable IdentityStore L2,
Redis by default) with multi-key alias caching, negative caching, and in-progress dedup, plus
per-module custom metrics. Configuration and behavior are documented in the module README.

🧠 Rationale behind the change

Publishers using IntentIQ want server-side ID enrichment without shipping/licensing device
detection to the client. Implemented as a standard PBS module using the hooks framework (no direct
HTTP; uses the framework HttpClient). The L2 store is @ConditionalOnMissingBean, so partners can
swap Redis for their own backend or disable caching entirely. Device detection stays fully
server-side. Trade-off: winning bids are reported server-side rather than as true client renders.

🧪 Test plan

Unit-tested across the module (120 tests) covering the resolution hook, response/impression hook,
caching (L1/L2, negative, in-progress, alias back-fill), TTL policy, metrics, Redis store/stats,
and Spring config. JaCoCo: 97% instruction coverage, no class below 90%. Verified locally with
mvn -f extra/pom.xml -pl modules/intentiq-identity clean test checkstyle:check — all green,
0 checkstyle violations. Also smoke-tested the bundle per the README "Running the demo" steps.

🏎Quality check

• Are your changes following our code style guidelines?
• Are there any breaking changes in your code? — No; new module, opt-in via execution plan.
• Does your test coverage exceed 90%?
• Are there any erroneous console logs, debuggers or leftover code in your changes? — None.