docs(branch-spec): feature-frontend-binary-file-io-store-contract 채움

MDN 근거 3건 수집 후 결정 7개를 근거 기반으로 확정하고 §구현 가이드
4개 sub-section 을 채웠다. 조사에서 기존 계약 2건의 사실 오류가 나왔다.

- EVICTION_SCOPE_DRIFT: 브라우저 eviction 은 origin 전량 삭제이므로
  FE-REG-STORAGE.evictionOrder 는 애플리케이션 주도 정리에만 유효
- CACHE_STORAGE_CONSTRAINT_DRIFT: Cache Storage 는 SW 전용이 아니다
  (Window.caches 접근 가능). FE-D027 의 제한은 정책이지 플랫폼 제약이 아님
- NO_GROUND_TRUTH: ca-tmpl 은 backend 전용이라 이 branch 에 미적용
- CAPABILITY_NAME_COLLISION: ca-tmpl capabilities.yaml 과 다른 개념

신규 raw: mdn-storage-quotas-eviction-persistence,
mdn-file-system-access-opfs, mdn-object-url-cache-storage
6개 신규 branch-note 전부에 governing_docs 추가.
This commit is contained in:
DongHyeonka
2026-07-28 15:24:19 +09:00
parent 55de4f55b0
commit 7bcb54c464
9 changed files with 415 additions and 13 deletions
@@ -0,0 +1,104 @@
---
title: MDN — File System API (showOpenFilePicker / showSaveFilePicker / Origin Private File System)
source_type: official-doc
url: https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
archive_url:
related_branches: [feature-frontend-binary-file-io-store-contract, feature-frontend-large-object-transfer-contract]
related_projects: [ca-skeleton-frontend]
tags: [frontend, file-io, opfs, file-system-access, browser]
created: 2026-07-28
---
# MDN — File System API (showOpenFilePicker / showSaveFilePicker / Origin Private File System)
> Layer: `raw/` — 외부 자료의 **원문 발췌·출처 기록**.
## 활용 branch (필수, 최소 1개+)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| `[[raw/branch-notes/feature-frontend-binary-file-io-store-contract]]` | `FileDialogPort` 의 메커니즘 선택·fallback 조건, OPFS backend 를 opt-in 으로 두는 근거, picker 취소의 실패 매핑 |
| `[[raw/branch-notes/feature-frontend-large-object-transfer-contract]]` | 대용량 순차 write 를 OPFS 로 처리할 때의 worker 제약 |
## 출처
- 원본 URL: https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
- 보조 URL: https://developer.mozilla.org/en-US/docs/Web/API/Window/showOpenFilePicker , https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker
- 아카이브 URL:
- 저자 / 조직: MDN Web Docs (Mozilla)
- 발행일: (문서 지속 갱신)
- 마지막 확인일: 2026-07-28
## 왜 저장했는지
`FileDialogPort``BlobStorePort` 의 메커니즘을 추측으로 정하지 않기 위해. 특히 (a) File System Access API 를 default 로 삼아도 되는지, (b) OPFS 의 동기 API 가 어느 실행 컨텍스트에서만 가능한지, (c) picker 취소가 어떤 예외로 오는지를 확인했다.
## 핵심 인용
> [§showOpenFilePicker — Baseline] "**Limited availability** — This feature is not Baseline because it does not work in some of the most widely-used browsers."
> [§showOpenFilePicker] "The `showOpenFilePicker()` method of the `Window` interface shows a file picker that allows a user to select a file or multiple files and returns a handle for the file(s)."
> [§showOpenFilePicker — Security] "Transient user activation is required. The user has to interact with the page or a UI element in order for this feature to work."
> [§showOpenFilePicker — Exceptions] "`AbortError` `DOMException` — Thrown if the user dismisses the prompt without making a selection, or if the user agent deems any selected files too sensitive or dangerous."
> [§showSaveFilePicker] "The `showSaveFilePicker()` method of the `Window` interface shows a file picker that allows a user to save a file. Either by selecting an existing file, or entering a name for a new file."
> [§showSaveFilePicker — Return value] "A `Promise` whose fulfillment handler receives a `FileSystemFileHandle` object."
> [§showSaveFilePicker — Exceptions] "`AbortError` `DOMException` — Thrown if the user dismisses the file picker without selecting or inputting a file, or if the user agent deems any selected files too sensitive or dangerous."
> [§showSaveFilePicker — Secure context] "**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers."
> [§OPFS] "The **origin private file system** (OPFS) is a storage endpoint provided as part of the File System API, which is private to the origin of the page and not visible to the user like the regular file system."
> [§OPFS] "The OPFS is subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism (for example IndexedDB API)."
> [§OPFS] "Permission prompts and security checks are not required to access files in the OPFS."
> [§OPFS] "It also has a set of synchronous calls available (other File System API calls are asynchronous) that can be run inside web workers only so as not to block the main thread."
> [§OPFS] "The OPFS offers low-level, byte-by-byte file access, which is private to the origin of the page and not visible to the user. As a result, it doesn't require the same series of security checks and permission grants and is therefore faster than File System Access API calls."
> [§OPFS] "Web Workers don't block the main thread, which means you can use the synchronous file access APIs in this context."
> [§OPFS] "Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user."
> [§OPFS] "Clearing storage data for the site deletes the OPFS."
## 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| C1 | `showOpenFilePicker()` 는 Baseline 이 아니며 널리 쓰이는 일부 브라우저에서 동작하지 않는다 | [§Baseline] "not Baseline because it does not work in some of the most widely-used browsers" | `official-reference` | File System Access picker 계열 | 어떤 브라우저가 미지원인지 구체 목록 |
| C2 | picker 계열은 transient user activation 을 요구한다 — 사용자 제스처 없이 호출할 수 없다 | [§Security] "Transient user activation is required." | `official-reference` | `showOpenFilePicker`·`showSaveFilePicker` | `<input type=file>` 도 같은 제약을 갖는다는 뜻은 아님 |
| C3 | 사용자가 picker 를 닫으면 `AbortError` DOMException 이 던져진다 | [§Exceptions] "Thrown if the user dismisses the prompt without making a selection" | `official-reference` | picker 계열 | 취소와 "위험한 파일 거부"가 구분되어 온다는 뜻은 아님 — 같은 예외다 |
| C4 | picker 계열은 secure context(HTTPS)에서만 사용 가능하다 | [§Secure context] "available only in secure contexts (HTTPS)" | `official-reference` | picker 계열 | localhost 예외 여부 |
| C5 | OPFS 의 동기 접근 API 는 **web worker 안에서만** 실행할 수 있다 | [§OPFS] "can be run inside web workers only so as not to block the main thread" | `official-reference` | `createSyncAccessHandle()` | 비동기 OPFS API 도 worker 전용이라는 뜻은 아님 |
| C6 | OPFS 는 권한 프롬프트·보안 검사를 요구하지 않아 File System Access API 호출보다 빠르다 | [§OPFS] "it doesn't require the same series of security checks and permission grants and is therefore faster than File System Access API calls" | `official-reference` | OPFS byte 접근 | IndexedDB 보다 빠르다는 뜻은 아님 — 비교 대상은 File System Access API 다 |
| C7 | OPFS 는 다른 origin-partitioned storage 와 동일한 quota 제약을 받는다 | [§OPFS] "subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism" | `official-reference` | OPFS | OPFS 가 별도 quota 를 갖는다는 뜻은 아님 |
| C8 | OPFS 는 사용자에게 보이지 않으며 사이트 저장소를 지우면 함께 삭제된다 | [§OPFS] "Clearing storage data for the site deletes the OPFS." | `official-reference` | OPFS | 사용자가 개별 파일만 지울 수 있다는 뜻은 아님 |
## 적용 경계
- 이 자료가 직접 증명하는 것:
- `C1`~`C4`: picker 계열의 가용성·활성화 요구·예외·보안 컨텍스트
- `C5`~`C8`: OPFS 의 실행 컨텍스트 제약, 성능 비교 대상, quota 귀속, 삭제 조건
- 이 자료가 증명하지 않는 것:
- `<a download>` + Blob URL fallback 이 picker 와 **동등**하다는 것 — MDN 은 fallback 이 덮어쓰기를 지원하지 않는다고만 언급한다
- OPFS 가 IndexedDB 보다 빠르다는 것 (`C6` 의 비교 대상은 File System Access API 다)
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 대상 브라우저 매트릭스 확정 후 picker 지원 여부 실측 (`FE-Q-007` 브라우저 지원 매트릭스)
- OPFS 순차 write 가 IndexedDB 대비 유리한지의 자체 벤치마크
## 메모
- 인용 1 해석 후보 (미검증): `C1` 때문에 `FileDialogPort` 는 File System Access 를 **default 로 가정할 수 없고**, `<input type=file>` 을 기준선으로 두고 picker 를 progressive enhancement 로 얹는 구조가 안전하다.
- 인용 2 해석 후보 (미검증): `C5` 는 OPFS 를 쓰려면 `WorkerTaskPort`(`FE-OC-032`)와의 결합이 필요하다는 뜻이 될 수 있다 — 동기 API 를 쓸 경우에 한정.
- 추가로 봐야 할 동일 출처 페이지: `FileSystemFileHandle.createWritable()`, `FileSystemSyncAccessHandle`
## 관련
- 같은 주제 다른 official-doc: `[[raw/official-docs/mdn-storage-quotas-eviction-persistence]]`, `[[raw/official-docs/mdn-object-url-cache-storage]]`
- 이 자료를 인용한 wiki 요약: 생성 전
@@ -0,0 +1,84 @@
---
title: MDN — URL.createObjectURL() / CacheStorage
source_type: official-doc
url: https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static
archive_url:
related_branches: [feature-frontend-binary-file-io-store-contract, feature-frontend-background-execution-worker-contract]
related_projects: [ca-skeleton-frontend]
tags: [frontend, blob, object-url, cache-storage, service-worker, browser]
created: 2026-07-28
---
# MDN — URL.createObjectURL() / CacheStorage
> Layer: `raw/` — 외부 자료의 **원문 발췌·출처 기록**.
## 활용 branch (필수, 최소 1개+)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| `[[raw/branch-notes/feature-frontend-binary-file-io-store-contract]]` | object URL 수명 소유 결정(`D1`), Cache Storage backend 의 실행 컨텍스트 전제 |
| `[[raw/branch-notes/feature-frontend-background-execution-worker-contract]]` | service worker 안에서 object URL 을 만들 수 없다는 제약, Cache Storage 버전 파티션 |
## 출처
- 원본 URL: https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static
- 보조 URL: https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage
- 아카이브 URL:
- 저자 / 조직: MDN Web Docs (Mozilla)
- 발행일: (문서 지속 갱신)
- 마지막 확인일: 2026-07-28
## 왜 저장했는지
(a) object URL 을 adapter 가 쌍으로 소유해야 한다는 결정에 외부 근거가 있는지, (b) Cache Storage 가 service worker 전용인지를 확인하기 위해. (b) 는 `FE-D027` 의 "Cache Storage 는 service worker 호스팅 response cache 전용" 서술이 **기술 제약인지 정책인지** 가르는 지점이었다.
## 핵심 인용
> [§URL.createObjectURL] "To release an object URL, call `revokeObjectURL()`."
> [§URL.createObjectURL — Availability] "This feature is _not_ available in Service Workers due to its potential to create memory leaks."
> [§CacheStorage] "The `CacheStorage` interface represents the storage for `Cache` objects."
> [§CacheStorage] "Provides a master directory of all the named caches that can be accessed by a `ServiceWorker` or other type of worker or `window` scope (you're not limited to only using it with service workers)."
> [§CacheStorage] "You can access `CacheStorage` through the `Window.caches` property in windows or through the `WorkerGlobalScope.caches` property in workers."
> [§CacheStorage — Examples] "Delete any old caches to respect user's disk space."
> [§CacheStorage.delete] "Finds the `Cache` object matching the `cacheName`, and if found, deletes the `Cache` object and returns a `Promise` that resolves to `true`. If no `Cache` object is found, it resolves to `false`."
> [§CacheStorage.keys] "Returns a `Promise` that will resolve with an array containing strings corresponding to all of the named `Cache` objects tracked by the `CacheStorage`. Use this method to iterate over a list of all the `Cache` objects."
## 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| C1 | object URL 은 명시적으로 `revokeObjectURL()` 을 호출해야 해제된다 | [§createObjectURL] "To release an object URL, call `revokeObjectURL()`." | `official-reference` | 모든 object URL | 해제하지 않으면 반드시 누수가 된다는 정량적 근거 |
| C2 | `createObjectURL`**메모리 누수 가능성 때문에** Service Worker 에서 제공되지 않는다 | [§Availability] "not available in Service Workers due to its potential to create memory leaks" | `official-reference` | Service Worker 컨텍스트 | window/worker 에서 누수가 발생하지 않는다는 뜻은 아님 — 오히려 같은 위험의 존재를 시사 |
| C3 | `CacheStorage` 는 service worker 전용이 아니며 window scope 에서도 접근 가능하다 | [§CacheStorage] "you're not limited to only using it with service workers" | `official-reference` | `Window.caches`·`WorkerGlobalScope.caches` | service worker 없이 오프라인 응답 가로채기가 가능하다는 뜻은 아님 |
| C4 | MDN 예제는 캐시 이름에 버전을 넣고 오래된 캐시를 삭제하는 패턴을 제시한다 | [§Examples] "Delete any old caches to respect user's disk space." (예제: `` `myapp-${cacheVersion}` ``) | `official-reference` | Cache Storage 운영 | 특정 버전 문자열 형식이 표준이라는 뜻은 아님 |
| C5 | `CacheStorage.keys()` 로 캐시 목록을 열거하고 `delete(cacheName)` 로 개별 캐시를 지울 수 있다 | [§CacheStorage.keys] "Use this method to iterate over a list of all the `Cache` objects." | `official-reference` | Cache Storage | 개별 응답 단위 eviction 순서를 브라우저가 보장한다는 뜻은 아님 |
## 적용 경계
- 이 자료가 직접 증명하는 것:
- `C1`·`C2`: object URL 의 해제 책임과 Service Worker 미제공 사실
- `C3`~`C5`: Cache Storage 의 접근 범위와 버전 파티션 운영 수단
- 이 자료가 증명하지 않는 것:
- object URL 을 **adapter 가** 소유해야 한다는 것 — MDN 은 해제 필요성만 말하고 소유 주체는 말하지 않는다. 소유 주체는 project decision 이다
- Cache Storage 를 service worker 로 제한하는 것이 필요하다는 것 — 오히려 `C3` 은 그 반대를 말한다
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- `FE-D027` 의 "Cache Storage = SW 호스팅 전용" 이 기술 제약이 아니라 **정책**임을 문서에 명시할 것
## 메모
- 인용 1 해석 후보 (미검증): `C2` 는 "Service Worker 에서 못 쓴다" 는 가용성 사실이지만, 그 **사유**가 memory leak 이라는 점에서 window 컨텍스트에서도 해제 규율이 필요하다는 방증으로 읽을 수 있다. 다만 이는 해석이며 MDN 이 직접 말한 것은 아니다.
- 인용 2 해석 후보 (미검증): `C3` 때문에 `FE-D027` 의 Cache Storage 서술은 `CATEGORY_DRIFT` 성격의 정정이 필요하다 — 기술적으로 불가능한 것이 아니라 우리가 그렇게 **정한** 것이다.
- 추가로 봐야 할 동일 출처 페이지: `URL.revokeObjectURL()`, `Cache.put()` 의 quota 동작
## 관련
- 같은 주제 다른 official-doc: `[[raw/official-docs/mdn-storage-quotas-eviction-persistence]]`, `[[raw/official-docs/mdn-file-system-access-opfs]]`
- 이 자료를 인용한 wiki 요약: 생성 전
@@ -0,0 +1,94 @@
---
title: MDN — Storage quotas and eviction criteria / StorageManager.persist()
source_type: official-doc
url: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria
archive_url:
related_branches: [feature-frontend-binary-file-io-store-contract, feature-frontend-large-object-transfer-contract, feature-frontend-cache-tier-cross-tab-invalidation-contract]
related_projects: [ca-skeleton-frontend]
tags: [frontend, storage, indexeddb, opfs, cache-storage, quota, browser]
created: 2026-07-28
---
# MDN — Storage quotas and eviction criteria / StorageManager.persist()
> Layer: `raw/` — 외부 자료의 **원문 발췌·출처 기록**.
## 활용 branch (필수, 최소 1개+)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| `[[raw/branch-notes/feature-frontend-binary-file-io-store-contract]]` | `BlobStorePort` 의 quota 실패 매핑, eviction 정책, `evictionOrder` 필드의 실제 적용 범위 |
| `[[raw/branch-notes/feature-frontend-large-object-transfer-contract]]` | `UPLOAD_PART_STATE` 를 재개 가능 전송의 correctness 값으로 유지할 수 있는지의 조건 |
| `[[raw/branch-notes/feature-frontend-cache-tier-cross-tab-invalidation-contract]]` | 영속 캐시 tier 가 브라우저 eviction 에 노출되는 범위 |
## 출처
- 원본 URL: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria
- 보조 URL: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
- 아카이브 URL:
- 저자 / 조직: MDN Web Docs (Mozilla)
- 발행일: (문서 지속 갱신)
- 마지막 확인일: 2026-07-28
## 왜 저장했는지
`ca-skeleton-frontend``FE-REG-STORAGE``quotaFallback`·`evictionOrder` 필드를 정의했는데, 그 필드가 **브라우저 eviction 에도 적용되는지** 확인이 필요했다. 결과적으로 브라우저 eviction 은 origin 단위 전량 삭제라 per-key 순서가 적용되지 않는다는 사실을 확인했고, 이는 `FE-D027`·`FE-D030` 의 전제를 바꾼다.
## 핵심 인용
> [§Storage limits — Firefox] "In Firefox, the maximum storage space an origin can use in best-effort mode is whichever is the smaller of: 10% of the total disk size where the profile of the user is stored. Or 10 GiB, which is the _group limit_ that Firefox applies to all origins that are part of the same site."
> [§Storage limits — Chromium] "In browsers based on the Chromium open-source project, including Chrome and Edge, an origin can store up to 60% of the total disk size in both persistent and best-effort modes."
> [§Storage limits — Web Storage] "Web Storage, which can be accessed by using the `localStorage` and `sessionStorage` properties of the `window` object, is limited to 10 MiB of data maximum on all browsers."
> [§Storage limits — Web Storage] "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin."
> [§Eviction] "Browsers use a Least Recently Used (LRU) policy to deal with this scenario. The data from the least recently used origin is deleted. If storage pressure continues, the browser moves on to the second least recently used origin, and so on, until the problem is resolved."
> [§Eviction] "When an origin's data is evicted by the browser, all of its data, not parts of it, is deleted at the same time. If the origin had stored data by using IndexedDB and the Cache API for example, then both types of data are deleted."
> [§Eviction] "This eviction mechanism only applies to origins that are not persistent and skips over origins that have been granted data persistence by using `navigator.storage.persist()`."
> [§Eviction — Safari] "Safari proactively evicts data when cross-site tracking prevention is turned on. If an origin has no user interaction, such as click or tap, in the last seven days of browser use, its data created from script will be deleted."
> [§Persistence] "Best-effort: this is the way that data is stored by default. Best-effort data persists as long as the origin is below its quota, the device has enough storage space, and the user doesn't choose to delete the data via their browser's settings."
> [§Persistence] "Persistent: an origin can opt-in to store its data in a persistent way. Data stored this way is only evicted, or deleted, if the user chooses to, by using their browser's settings."
> [§StorageManager.persist] "The `persist()` method of the `StorageManager` interface requests permission to use persistent storage, and returns a `Promise` that resolves to `true` if permission is granted and bucket mode is persistent, and `false` otherwise."
> [§StorageManager.persist] "The browser may or may not honor the request, depending on browser-specific rules."
## 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| C1 | 브라우저 eviction 은 origin 단위로 **전량** 삭제하며 일부만 지우지 않는다 | [§Eviction] "all of its data, not parts of it, is deleted at the same time" | `official-reference` | best-effort 모드의 모든 origin-partitioned storage | 애플리케이션이 스스로 수행하는 선택적 정리까지 금지한다는 뜻은 아님 |
| C2 | IndexedDB 와 Cache API 는 같은 eviction 단위에 속해 함께 삭제된다 | [§Eviction] "If the origin had stored data by using IndexedDB and the Cache API for example, then both types of data are deleted" | `official-reference` | IndexedDB · Cache API · File System API(OPFS) | 각 API 의 개별 quota 가 존재한다는 뜻은 아님 |
| C3 | eviction 은 LRU origin 순서로 일어난다 | [§Eviction] "Browsers use a Least Recently Used (LRU) policy... The data from the least recently used origin is deleted" | `official-reference` | best-effort origin | origin **내부**의 key 우선순위를 브라우저가 존중한다는 뜻은 아님 |
| C4 | `navigator.storage.persist()` 로 허가받은 origin 은 LRU eviction 대상에서 제외된다 | [§Eviction] "skips over origins that have been granted data persistence by using `navigator.storage.persist()`" | `official-reference` | 허가가 실제로 부여된 origin | 요청하면 항상 허가된다는 뜻은 아님 |
| C5 | persist 요청의 허가 여부는 브라우저 재량이며 boolean 으로 반환된다 | [§StorageManager.persist] "The browser may or may not honor the request, depending on browser-specific rules." | `official-reference` | 모든 지원 브라우저 | 특정 브라우저의 허가 조건이 무엇인지 |
| C6 | Web Storage(`localStorage`/`sessionStorage`)는 origin 당 5 MiB 수준이며 IndexedDB 계열과 별도 한도를 가진다 | [§Storage limits] "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin." | `official-reference` | 모든 브라우저 | Web Storage 가 eviction 에서 제외된다는 뜻은 아님 |
| C7 | Safari 는 cross-site tracking prevention 활성 시 7일간 사용자 상호작용이 없으면 script 로 만든 데이터를 삭제한다 | [§Eviction — Safari] "If an origin has no user interaction... in the last seven days of browser use, its data created from script will be deleted." | `official-reference` | Safari + ITP 활성 | 다른 브라우저도 같은 정책을 쓴다는 뜻은 아님 |
## 적용 경계
- 이 자료가 직접 증명하는 것:
- `C1`~`C3`: 브라우저 주도 eviction 의 단위와 순서
- `C4`·`C5`: persist() 의 효과와 불확실성
- 이 자료가 증명하지 않는 것:
- 애플리케이션이 quota 압박 시 **스스로** 어떤 순서로 정리해야 하는지 — 그건 제품 결정이다
- 특정 브라우저가 persist 를 허가하는 구체 조건
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- `UPLOAD_PART_STATE` 가 재개 가능 전송에 실제로 충분히 오래 살아남는지 (Safari 7일 규칙 + persist 미허가 조합)
## 메모
- 인용 1 해석 후보 (미검증): `FE-REG-STORAGE.evictionOrder` 는 **애플리케이션 주도 정리 순서**로만 유효하다. 브라우저 eviction 에는 적용되지 않으므로 필드 설명에 그 경계를 명시해야 한다.
- 추가로 봐야 할 동일 출처 페이지: `StorageManager.estimate()`, `navigator.storage.persisted()`
## 관련
- 같은 주제 다른 official-doc: `[[raw/official-docs/mdn-file-system-access-opfs]]`, `[[raw/official-docs/mdn-object-url-cache-storage]]`
- 이 자료를 인용한 wiki 요약: 생성 전