Fork network integration + LMDB growth fix (1GB map, 7-day retention)

[kahlos]

Brings the merged fork-network work (C1/C3/C4/C7 ports, composed preprocess wrapper) together with a fix for the LMDB storage growth issue.

LMDB fix (f0232cd)

• storage.max_size default raised 256MB → 1GB. LMDB's map is fixed at open; at the 256MB ceiling every write fails with MDB_MAP_FULL and session-reuse persistence silently stops (non-fatal: HTTP still 200, warn + continue).
• retention_days default 14 → 7 so the 6-hourly cleanup reclaims space sooner.
• README documents the CONFIG_STORAGE__MAX_SIZE / CONFIG_STORAGE__RETENTION_DAYS overrides and the restart-after-raise requirement.
• Live deployment restarted against the reopened 1GB env: verified via store write/find/read/delete through the app's own code path; zero MDB_MAP_FULL errors since restart.

Fork network integration (cf44679 and earlier merges)

• C1: native Gemini v1beta REST endpoints
• C3: runtime model discovery by name
• C4: request lifecycle hardening + observability
• C7: summary compaction for temporary/fallback flows (default file strategy, behavior-preserving)

No force-pushes; branch is a fast-forward of luuquangvu/main (10 commits ahead, 0 behind).

[luuquangvu]

@kahlos Thanks for contributing this PR. There are a few points I’m considering:

• Increasing the LMDB size will immediately take up hard drive space. Since this project is partly used on many low-end devices, increasing the size for users with higher demands should be left to user customization.
• The timeout/keepalive/recovery logic should already be handled by the upstream gemini-api library, so there’s no need to reinvent the wheel.
• The new oversized_context_strategy compaction mode doesn’t address cases where the input is very large but total turns are fewer than 8, so it’s not as effective as expected.
• config.yaml is used to build and run the container; renaming and ignoring it would break the published image.
• Runtime model discovery is unnecessary now, as fully dynamic models from RPC have been implemented, so a custom model is no longer needed.
• validate_session_on_init is redundant, since multiple RPC checks are enough to verify the client’s health.
• I’ve updated the logic to seamlessly handle temporary and guest modes while fully switching to dynamic models, but this has caused some conflicts with your PR.

[kahlos]

@luuquangvu Thanks for the detailed review — all six points are fair, and we've reconciled the integration accordingly (then integrated your 71c0db2/c8e0a83 into our fork).

Your point	Our resolution
LMDB size	Reverted: defaults back to 256 MB / 14 days; storage.max_size stays as the user knob
Timeout/keepalive	Agreed — verified the pinned lib already handles socket-stall (asyncio.wait_for per chunk), watchdog and connection refresh; our C4 was dropped
Compaction gate	Agreed — our gate early-returned at ≤8 messages, so large <8-turn inputs escaped it; your attachment fallback covers that case; C7 dropped
config.yaml	Upstream keeps config/config.yaml (not part of the follow-up PR); our repo's gitignored-credentials posture stays local-only
Runtime model discovery	Superseded by your dynamic AvailableModel; dropped
validate_session_on_init	Dropped; the client's account-status/watchdog checks cover it

Also fixed a latent bug found while integrating: _resolve_model_name calls client.resolve_model(...), which doesn't exist — the library exposes _resolve_model_by_name (same ValueError contract); see the follow-up PR.

Closing #5 as superseded — the reconciled survivors (unobjected only) are in #6.

[kahlos]

Closed as superseded by #6 (reconciled survivors).