[Windows] Upgrading over an existing install wipes Solr's core registry — all previously-processed cases silently vanish from Review (data itself is not lost)

[Mahathi1207]

Summary

Installing a newer build over an existing install (no uninstall first) silently resets Solr's
core registry (solr.xml) to its pristine default. Every previously-processed case instantly
disappears from Review — "No results found," no error — even though the underlying index data
is completely untouched on disk. Reproduced twice, independently: once via reinstalling, once
via a full system reboot.

Environment

• Build: 10.8.6-SNAPSHOT / gb260671 → ga6a7a33
• Windows: Windows 11 Home | Clean install? No — existing install with 13 previously-
  processed cases
• Severity: Blocker. Upgrading is exactly what every real user will eventually do to get bug
  fixes — and it wipes access to all prior case data with zero error or recovery path.

Steps to Reproduce

1. Have an existing install with at least one processed case.
2. Run the installer again over it (no uninstall).
3. Start services normally.
4. Open Review, select any previously-processed case.

Expected vs Actual

Expected: Cases stay accessible after an upgrade, same as any other restart.
Actual: "No results found" for everything. Solr's admin API confirms zero registered cores
("status":{}); querying any case core directly returns a flat 404.

Root Cause

Cores are only ever registered via a one-time CREATE admin call
(SolrIndex.java:285-288) when a project is first processed. solr.xml has persistent="true",
so this should survive restarts — and it does, normally (confirmed below). But the installer
overwrites solr.xml with Solr's pristine, bundled-since-2013 default every time it runs,
discarding all accumulated registrations. The actual index data lives in separate,
untouched data_N directories.

Confirmed: post-upgrade, solr.xml was byte-identical to the pristine 227-byte default, with a
filesystem timestamp of Oct 3 2013 — never modified, not merged with prior entries.

Recovery (confirmed, but requires knowledge no normal user has)

Manually re-issuing the app's own CREATE call once per existing data_N directory instantly
restores full access with correct document counts. A subsequent Solr restart then correctly
reloads everything from the now-populated solr.xml on its own — confirming this is a one-time
install-step bug, not an ongoing persistence failure.

Notes

This did NOT occur across several earlier build upgrades earlier in this same session
(10.8.4.1 → 10.8.5-SNAPSHOT → 10.8.5) — cases persisted fine then. Likely a recent regression,
possibly related to the Windows service-launch changes already known to be in this build range.