docs: record round k gate failure and round l plan

docs/PLAYOUT_OPERATIONS.md

@@ -14,7 +14,7 @@
 | `s5025` trusted 수동 파일 | 외부 CP949 source 통합 검증 통과; 실제 파일/환경은 계속 Git 밖에서 회차별 preflight |
 | `s5006` `Video\큐브배경.vrv` | 현재 승인 Cuts root에서 누락 |
 | `s6001` 해외지수 영상 | 국가별 `Video\20201008_<국가>.vrv` 13개가 현재 승인 Cuts root에서 누락; 외부자산 필요 |
-| 이번 마이그레이션 WebView workflow의 실제 Tornado2 검증 | **최신 성공은 승인된 5001/5074 범위의 Round H. Round J는 pre-dispatch 명령 0건으로 종료됐고 수정된 Round K는 Gate A 승인 대기; 35개 전체의 실제 PGM 검증으로 확대 해석하지 않음** |
+| 이번 마이그레이션 WebView workflow의 실제 Tornado2 검증 | **최신 성공은 승인된 5001/5074 범위의 Round H. Round J/K는 각각 pre-dispatch 명령 0건으로 종료됐고 수정된 Round L은 Gate A 승인 대기; 35개 전체의 실제 PGM 검증으로 확대 해석하지 않음** |
 
 1.0.2 Visual Studio 개발 등록본을 signed 1.0.3으로 교체할 때 `Remove-AppxPackage -PreserveApplicationData`를 사용했다. 재등록 구간에서 바뀐 파일은 Windows package Settings transaction log `settings.dat.LOG1/LOG2`뿐이었고, WebView LocalState와 외부 `%LOCALAPPDATA%\MBN_STOCK_WEBVIEW` 운영 데이터는 삭제·덮어쓰지 않았다. 이 패키지 검증 회차는 기본 설정 부재와 환경 override 0건을 확인한 `DryRun`으로만 실행했으며 Tornado 실제 명령은 보내지 않았다.
 
@@ -90,7 +90,7 @@ range에는 그 추가 PREPARE/PLAY를 반영하지 않은 불일치가 있었
 
 이 실패 뒤 `maximumAutomaticRefreshesPerTakeIn` trusted JSON-only 상한을 추가했다. 기본 `null`은 원본 연속 갱신을 유지하고, 실제 검증 설정의 `1`은 scheduler와 실제 refresh dispatch 경계에서 두 번째 실행을 이중 차단한다. 상태는 `refreshCompletedCount`, `refreshMaximumCount`, `refreshLimitReached`를 제공하며, 마지막 refresh `OnScenePlayed`가 drain되기 전에는 count가 상한에 도달해도 `refreshLimitReached=false`를 유지한다. 검증은 `completed=1`, `maximum=1`, `limitReached=true`, `refreshActive=false`, `playCompletionPending=false`를 모두 확인해야 한다. 변경된 package는 Round I 승인/계획을 재사용할 수 없으며 새 package hash, 새 회차 계획과 새 CONNECT/PREPARE/TAKE IN 승인이 필요하다.
 
-### Round J pre-dispatch 실패와 Round K 시간 검증
+### Round J/K pre-dispatch 실패와 Round L 교정
 
 Round J `MBNWEB-20260712-J`는 계획 SHA-256
 `8B51E43AFC5F0E330A8DEF3B38DF071B071E5814FC96258AA9505935D1B43956`에 대한
@@ -111,10 +111,29 @@ Round K `MBNWEB-20260712-K`는 별도 회차이며 계획 SHA-256은
 거부와 `60.125초` 보존을 확인한다. Gate A는 승인 파일 생성 뒤 정확히 계획·승인·
 Live 설정·installed manifest·계획에 SHA로 묶인 helper 7개만 있는지 계획 해석 전과
 capability 생성 직전에 검사한다. 폴더, reparse, 미지·임시·partial·static-test 파일,
-누락과 중복은 모두 fail-closed다. K는 새 Gate A 승인을 받기 전에는 어떤 앱이나
-Tornado 명령도 실행하지 않는다. 현재 승인 전 운영 폴더는 정확히 10개 파일이며,
-Gate A 예산은 CONNECT 1회, PREPARE 5001/page 1 1회, 명확한 known-outcome 중단의
-DISCONNECT 최대 1회다. TAKE IN, NEXT, Page NEXT, DB write와 retry는 0이다.
+누락과 중복은 모두 fail-closed다.
+
+K Gate A는 승인 시간 계산을 통과했지만 설치 runtime manifest의 culture sort가 strict
+ordinal 검사를 만족하지 않아 execution marker 전에 `FAIL_KNOWN_CLEANED`로 끝났다.
+manifest 289개 항목과 내용은 정상이지만 ordinal 역전이 41개였고 첫 역전은
+`clrjit.dll → Config/appsettings.example.json`이다. 앱 launch/CONNECT/PREPARE와
+금지 명령은 모두 0건이며 `OutcomeUnknown=false`다. 결과 SHA-256은
+`E17FE1EE451A5D9E2B73CCB3D039B5AA90998CC35E3E973148614D32E76D1482`다. K 승인과
+예산은 폐기하며 재사용하지 않는다.
+
+Round L은 289개 path/length/SHA-256을 그대로 두고 `[StringComparer]::Ordinal`로만
+재정렬했다. manifest SHA-256은
+`9631E8188E10F23970F43593B705957A215AE01E2760FE714B08518DB0571A9B`이며 역전 0,
+K/L 의미 집합 289/289 동일, `ko-KR/en-US/tr-TR` 불변성을 확인했다. Gate A/B 모두
+exact schema, NFC와 안전 경로, exact/대소문자 충돌, strict ordinal 순서를 검증한다.
+Node 계획 생성기의 18자리 start ticks 반올림도 승인 전에 발견해 Int64 보존 회귀를
+추가했다. 최종 L 계획 SHA-256은
+`23E3A6A5400166A47835E146DCC2D19C181E2100D1485DB428F1B10718D89928`이다. 승인 전
+운영 폴더는 정확히 10개 파일이며 앱/Tornado 명령은 0건이다. Gate A 예산은 CONNECT
+1회, PREPARE 5001/page 1 1회, 명확한 known-outcome 중단의 DISCONNECT 최대 1회다.
+TAKE IN, NEXT, Page NEXT, DB write와 retry는 0이다. 세부 계획은
+[`LIVE_VALIDATION_PLAN_MBNWEB-20260712-L.md`](LIVE_VALIDATION_PLAN_MBNWEB-20260712-L.md)에
+고정했다.
 
 이 실제 Live PGM 증거는 회차에 허용된 5001과 5074에 한정된다. 35개 scene builder 전체 동등성은 자동 테스트, 55-query 실데이터 smoke와 [`SCENE_EQUIVALENCE.md`](SCENE_EQUIVALENCE.md) 매트릭스로 유지하며, 나머지 scene이 실제 PGM에서 각각 송출됐다는 의미로 기록하지 않는다.