feat: page entities with StableBTreeMap.range instead of probing every id

[deucalioncodes]

Closes #14
Companion to smart-social-contracts/basilisk#57 (StableBTreeMap.range).

What

Listing paths (load_some, find, instances, rebuild_field_index) read a page of entities with one ordered range call per digit-count bucket instead of probing Type@1..Type@max_id with three get()s per id. Deleted ids cost nothing; cost tracks rows returned, not the highest id ever issued.

File	Change
storage.py	Optional Storage.range(start, end=None, limit); supports_range(); storage_sort_key() and MemoryStorage.range that order keys exactly like the canister (Basilisk str keys sort shorter-first, then bytewise)
db_engine.py	Database.max_id(), Database.load_page(type, from_id, count, max_id=None) -> [(id, data)]. Range path walks [Type@{lo}, Type@{':'*d}) per digit count (tightened to Type@{max_id+1} in the last bucket); custom string ids inside a bucket are skipped and the range resumed at the next possible sequential id so pages stay full. Probe fallback when the backend has no range
entity.py	load_some → load_page (identity map first, shared _hydrate() with load); rebuild_field_index batches over live entities with the same cursor contract; __init__ skips the max-id counter re-read when _loaded=True; per-row INFO log removed
tests/entrypoint*.sh	Download the template attached to the installed Basilisk release (v{version}) with the -ic1 rolling asset as fallback, instead of the stale cpython-wasm-3.13.0 asset. Without this the on-chain tests would never exercise range
tests	MemoryStorage.range ordering; load_page buckets/gaps/custom ids ("1x", "007", "abc")/other types/max_id; load_some over ids 1–150 with deletions across three key lengths, cursor walk, custom ids at page boundaries, and a probe-only Storage giving identical results

No key format change and no migration. Type@id keys are untouched, so deployed canisters need nothing on upgrade.

Measured (MemoryStorage instrumented, 1000 Zones, every other id in the top half deleted)

Operation	Before	After
load_some(1, 50) cold	150 reads	1 read + 2 range calls (50 rows)
load_some(501, 50) cold, 50 % deleted region	250 reads	1 read + 1 range call
load_some(1, 1000) / instances() / find() cold	2 751 reads	1–2 reads + 4 range calls (750 rows)
load("42") cold	2 reads	1 read
Local CPU, 1000-row scan	28.9 ms	17.0 ms

Verification done locally

• tests/run_test.sh equivalent: all 18 local modules pass (16 in the script + context, hooks); ./run_linters.sh clean (black, isort, flake8, mypy).
• Deployed tests/src/main.py on a local icp replica with a Basilisk template built from basilisk#57: database, entity, indexed_fields, relationships, enhanced_relations, serialization, namespaces, alias_and_properties, mixins, properties, audit, example_1, example_2 all return 0; entity rows identical before/after an upgrade.
• Ran the same modules on the current published template (no range) — the fallback path is what CI's Test on IC exercises until Basilisk ships the new template.

Sequencing

1. Merge basilisk#57, let test-all.yml rebuild the template, cut Basilisk minor release.
2. Re-run this PR's CI (its Docker IC test does pip install --upgrade ic-basilisk and now fetches the v{version} template), merge, cut ic-python-db minor release via release.yml.