refactor: fair hit-rate for registry

[dkharms]

Description

In this PR I've reintroduced fix for too high registry cache hit-rate.

---

• I have read and followed all requirements in CONTRIBUTING.md;
• I used LLM/AI assistance to make this pull request;

If you have used LLM/AI assistance please provide model name and full prompt:

Model: {{model-name}}
Prompt: {{prompt}}

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.35878% with 48 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.54%. Comparing base (5fc2d11) to head (b10b266).

Files with missing lines	Patch %	Lines
frac/sealed.go	54.34%	37 Missing and 5 partials ⚠️
frac/remote.go	84.61%	5 Missing and 1 partial ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           0-scoped-cache     #499   +/-   ##
===============================================
  Coverage           71.53%   71.54%           
===============================================
  Files                 240      240           
  Lines               20187    20166   -21     
===============================================
- Hits                14441    14427   -14     
+ Misses               4657     4655    -2     
+ Partials             1089     1084    -5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🔴 Performance Degradation

Some benchmarks have degraded compared to the previous run.
Click on Show table button to see full list of degraded benchmarks.

Show table

Name	Previous	Current	Ratio	Verdict
MutexListAppend-4	a73114	8a760d
	194.53 MB/s	175.31 MB/s	0.90	🔴
Sealing_WithSort-4	a73114	8a760d
	40324408.00 B/op	73440320.00 B/op	1.82	🔴
	5389.00 allocs/op	2005410.00 allocs/op	372.13	🔴

[github-actions]

🔴 Performance Degradation

Some benchmarks have degraded compared to the previous run.
Click on Show table button to see full list of degraded benchmarks.

Show table

Name	Previous	Current	Ratio	Verdict
Sealing_WithSort-4	a73114	70a023
	40324408.00 B/op	72324136.00 B/op	1.79	🔴
	5389.00 allocs/op	2005388.00 allocs/op	372.13	🔴

[github-actions]

🔴 Performance Degradation

Some benchmarks have degraded compared to the previous run.
Click on Show table button to see full list of degraded benchmarks.

Show table

Name	Previous	Current	Ratio	Verdict
MutexListAppend-4	a73114	70a023
	194.53 MB/s	173.44 MB/s	0.89	🔴
Sealing_WithSort-4	a73114	70a023
	40324408.00 B/op	73440576.00 B/op	1.82	🔴
	5389.00 allocs/op	2005411.00 allocs/op	372.13	🔴

[github-actions]

🔴 Performance Degradation

Some benchmarks have degraded compared to the previous run.
Click on Show table button to see full list of degraded benchmarks.

Show table

Name	Previous	Current	Ratio	Verdict
Indexer-4	a73114	a30b4b
	678752766.00 B/op	764184994.00 B/op	1.13	🔴

[eguguchkin]

nit: Here the reader is not used, so there’s no need to initialise it. Even if it’s used somewhere later, it’s better to move the initialisation to that place.

I’d also remove it entirely from the permanent properties of Sealed.legacyReader.

[eguguchkin]

nit: I understand this is a one-time load, but for consistency, I would also create a reader via Session here.

I'd make it local (not a property of Sealed).

I also suggest doing the same for remote.