Improve MatterOpedia performance with client-side indexes

[st0rm-kr]

Why

While playing ATM10 with a large item catalog, MatterOpedia performed very poorly. Opening the screen and changing filters could stall or freeze the client because each interaction repeatedly rebuilt item stacks, scanned the complete catalog, and sorted the full result set on the render thread.

What changed

• Build one immutable client-side catalog after matter data is received.
• Precompute per-matter amount and display-name indexes, including missing and single-matter views.
• Use synchronous indexed queries, binary range lookup, and a bounded query cache instead of repeatedly filtering and sorting the full item list.
• Create ItemStacks only for entries visible in the 7x9 viewport.
• Rebuild name-dependent indexes after resource/language reloads and clear the catalog on logout.
• Reuse the number formatter used by the render path.
• Preserve existing empty matter query behavior.

This is client-side only and does not change packets, server calculation, or synchronization formats.

Validation

• ./gradlew clean test build
• 18 tests passed, 0 failures
• Test JAR verified manually in ATM10 by the reporter