we (web engine): Experimental web browser project to understand the limits of Claude

Implement origin-keyed Cache API storage master

Adds the Service Worker Cache API (`caches`, `Cache`) backed by an origin-keyed `CacheStorage` in `we-js` and an embedder-owned `CacheManager` in `we-browser`. - `we_js::cache`: storage model with `CacheRequest` / `CacheResponse`, Vary header matching, ignoreSearch/ignoreMethod/ignoreVary query options, GET-only put restriction, 206 rejection, fragment stripping, and a self-describing binary serialization for persistence. - `we_js::cache_api`: JS bindings for `caches.{open,has,keys,delete, match}` and `Cache.{match,matchAll,put,add,addAll,delete,keys}`, plus minimal `Request` / `Response` constructors. `Cache.add` / `addAll` decode `data:` URLs inline; HTTP fetch wiring is left for a follow-up. - `we_browser::cache_storage::CacheManager`: per-origin file persistence under `~/.we/caches/` with persistent and private-session partitions and an optional byte quota that evicts oldest entries before save. Wired into the document script-loader so navigation loads/saves the origin's caches around script execution. - Parser: allow reserved words after `.` (ES5+ identifier-name rule) so `caches.delete(...)` etc. parse. - E2E: `cache_api.we` scenario exercises the JS-level Cache API against a real (tuple) origin. Closes pierrelf.com/we issue 3mm26vcqnnw27.