fix: scope L2 cache removal to the OptionSet.options collection only

Keep the entity-level caches on Option and OptionSet (read-write) -- only
the collection-level cache on OptionSet.options was actually driving the
N+1: a collection-cache hit (cached id list) combined with an entity-cache
miss on one of those ids is what makes Hibernate resolve ids one at a time
instead of just re-running the collection's own `WHERE optionsetid = ?`
query. Removing the entity caches too was conflated with a separate,
unvalidated change (a service-layer Caffeine cache to compensate for lost
keyed lookups) that we decided not to pursue.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: jason-p-pickering

dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/option/hibernate/Option.hbm.xml

@@ -8,16 +8,7 @@
 <hibernate-mapping>
   <class name="org.hisp.dhis.option.Option" table="optionvalue">
 
-    <!-- L2 cache intentionally omitted: tracker preheat's query-driven bulk loads
-         unconditionally re-put every row on every fetch with no freshness check, and that put
-         path contends on Ehcache's per-key lock under concurrent imports. Live evidence
-         (ehcache_puts_total/ehcache_gets_total{cache="Option"}) showed put:get ratio climbing
-         from ~0.06 to ~0.19 as concurrent load ramped up, i.e. puts scaling faster than genuine
-         lookups, not just proportional volume growth. Also, on an L2 collection-cache hit for
-         OptionSet.options combined with an entity-cache miss for the individual Option rows,
-         Hibernate resolves each id one at a time instead of re-running the cheap
-         `WHERE optionsetid = ?` collection query, which is what produced the N+1; with no L2
-         cache configured here, that path no longer exists. -->
+    <cache usage="read-write" />
 
     <id name="id" column="optionvalueid">
       <generator class="native" />

dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/option/hibernate/OptionSet.hbm.xml

@@ -8,8 +8,7 @@
 <hibernate-mapping>
   <class name="org.hisp.dhis.option.OptionSet" table="optionset">
 
-    <!-- L2 cache intentionally omitted; see Option.hbm.xml for the rationale, same mechanism
-         applies here. -->
+    <cache usage="read-write" />
 
     <id name="id" column="optionsetid">
       <generator class="native" />
@@ -32,6 +31,14 @@
 
     <property name="version" />
 
+    <!-- Collection L2 cache intentionally omitted: a cache hit here (a cached list of Option
+         ids) combined with an entity-cache miss on one of those ids makes Hibernate resolve each
+         id one at a time instead of just re-running this bag's own query, which is what produced
+         an observed N+1 (thousands of individual `SELECT ... FROM optionvalue WHERE
+         optionvalueid = ?`) during tracker import. Without a cached id list to reconcile against
+         the entity cache, this collection always loads via its own single
+         `WHERE optionsetid = ?` query instead, which is fast (single query, indexed FK). Entity-
+         level caching for Option/OptionSet themselves is unaffected and still applies. -->
     <bag name="options" cascade="all" order-by="sort_order">
       <key column="optionsetid" foreign-key="fk_optionsetmembers_optionsetid" />
       <one-to-many class="org.hisp.dhis.option.Option" />