refactor: 프론트엔드 리펙토링

docs/architecture/decisions/VD-11-browser-file-and-origin-storage.md

@@ -189,17 +189,18 @@ chunk별 `CapabilityResult<Uint8Array>`를 반환한다. backend upload example
 실제 upload feature는 이 예시를 그대로 import하지 않고 purpose와 backend
 protocol에 맞게 contract를 더 좁힌다.
 
-현재 checkout의 browser source suite는 engine마다 같은 14개 case(File 2,
-IndexedDB 4, OPFS/Cache/StorageManager 각 1, cross-context invalidation 2,
-presigned streaming download/multipart upload/Image CDN 각 1)를 정의한다.
-promotion artifact는 Chromium/Firefox/WebKit 각각 14개, 총 42개를 모두
-실행해야 한다. WebKit은 현재
-host의 필수 native libraries(예:
-`libbacktrace.so.0`, `libevent-2.1.so.7`, `libjxl.so.0.8`,
-`libavif.so.16`과 WPE 계열) 부재로 실행되지 않았다. 보존 artifact는
-Chromium/Firefox 14개씩 총 28개만 통과했으므로
-`verify:browser-capability-evidence`가 실패하는 것이 정상이다. 세 engine
-evidence가 완성되기 전에는 product 상태를 `INSTALLED`로 올리지 않는다.
+browser capability promotion은 source suite가 정의한 동일 testcase set을
+Chromium/Firefox/WebKit에서 모두 실행해야 한다. 구체적인 case 개수는 이 결정
+문서에 고정하지 않는다. `verify:browser-capability-evidence`가 Chromium
+artifact에서 baseline set을 계산하고 Firefox/WebKit과의 set 동일성 및
+failure/error/skipped 0을 기계적으로 검증한다.
+
+engine별 native capability 차이는 testcase를 skip하는 이유가 아니다. capability가
+없으면 adapter의 명시적 unsupported/degraded result를 같은 testcase에서
+검증한다. baseline `<input type="file">` activation은 portable한
+`input.click()` 경로를 사용하고, `showOpenFilePicker()` 같은 API는 별도
+progressive enhancement로 유지한다. 세 engine evidence가 완성되기 전에는
+product 상태를 `INSTALLED`로 올리지 않는다.
 
 ## 선택 이후 필요한 구현