hotfix: wire StoreSizeLimit into tier1 linear pipeline

[sduchesneau]

Problem

Operators set StoreSizeLimit (e.g. 3.5GiB) but tier1's own linear (dev-mode) pipeline still tripped at the 1GiB default:

store "uniswap_v4:store_pools" became too big at 1579123284, maximum size: 1073741824

service/tier1.go hardcoded 0 when building its store ConfigMap, so it always fell back to DefaultStoreSizeLimit. Tier2 subrequests received the limit correctly via ProcessRangeRequest; only tier1's linear path ignored it.

Fix

• Add StoreSizeLimit to RuntimeConfig (next to StoresScratchSpace/StoresBackend) + WithStoreSizeLimit option, wired from the tier1 app config.
• tier1 store ConfigMap now passes runtimeConfig.StoreSizeLimit instead of 0.

Test

TestStoreSizeLimit sets a 1-byte limit on the tier1 linear pipeline and asserts ErrStoreAboveMaxSize. Verified it fails if the wiring regresses (limit dropped back to 0).

Additional e2e tests fixes

• mmap test was failing because the assertion for 'db files exist' was in a race condition with the deletion step. Now polls during the test to validate that files exist.

[sduchesneau]

🔍 Vulnerabilities of ghcr.io/streamingfast/substreams:28382f1

📦 Image Reference ghcr.io/streamingfast/substreams:28382f1

digest	sha256:e56f4cf17da19e27b6c1670eae370c4167f0ac71817d73dda204180af91d31aa
vulnerabilities
platform	linux/amd64
size	109 MB
packages	354

📦 Base Image ubuntu:24.04

also known as	noble noble-20260610
digest	sha256:52df9b1ee71626e0088f7d400d5c6b5f7bb916f8f0c82b474289a4ece6cf3faf
vulnerabilities