vPracticaHistorial repeats lookupOptions Seq Scans across its 4 archive branches

Split out of MARS-672 so it is not left implied. db-mars-cc measured, 2026-08-22 14:01:34-14:02:16Z: vPracticaHistorial took 12-13s and a vStudentAssignments/JTP-roster query took 18s, both with nested-loop plans repeating Seq Scans on lookupOptions (188 rows) many times per query. MARS-672 does NOT address this and cannot: bundling reduced concurrent CONNECTION COUNT, which was the exhaustion mechanism, but the view was already read once per render either way, so its per-call plan cost is unchanged. I initially framed the scan density as something the bundle would fix; db-mars-cc corrected that and the correction is the reason this item exists. Open question for the db lane: whether the four archive branches can resolve lookup labels once rather than per row, or whether labels should leave the view entirely and be mapped in Node from the already-cached getAllLookupOptions (MARS-658). Second query named above is a separate read path and may need its own look. Not urgent - no user-visible symptom on its own; it became visible only because 8-9 parallel connections ran these plans at the same instant and briefly saturated the instance.