fix(bridge): response file race condition + Run button regex + known issues

- Fix: processResponseFile no longer deletes response files for DOM observer
  approvals, allowing renderer pollResponse to find and serve them via HTTP
- Fix: Run button regex ^Run$ → ^Run to match 'Run Alt+⏎' button text
- Fix: BTN-DUMP diagnostic added to generateApprovalObserverScript (source)
- Doc: 2 new known issues (race condition, renderer script 3-location confusion)
- Doc: devlog entry #19

.agents/references/known-issues.md

@@ -130,11 +130,18 @@
 - **해결**: `scan()` 검색 범위를 `document.body` 전체로 확장, `Accept all` / `Reject all` 패턴 추가
 - **주의**: 패널+body 이중 검색 시 dedupe 필요 (같은 버튼이 두 번 잡힐 수 있음)
 
-### [2026-03-08] latestToolCallStep — 즉시 승인 감지 (stall 30초 대체)
-- **증상**: 이전 stall-based 감지는 RUNNING+delta=0+modTime frozen 30초 후에야 pending 생성
-- **원인**: `GetAllCascadeTrajectories` 응답의 `latestToolCallStep` 필드를 전혀 활용하지 않았음
-- **해결**: `latestToolCallStep.step`의 status 필드에서 `WAITING` 여부를 직접 체크 → 5초 poll 1회에 즉시 감지. Stall detection은 100초 fallback으로 유지
-- **주의**: `latestToolCallStep`의 정확한 protobuf 구조(status 필드 위치)는 런타임 덤프로 확정 필요 — 첫 실행 시 `[TOOL-STEP]` 로그 확인
+### [2026-03-08] GetCascadeTrajectorySteps — cascadeId 파라미터 발견
+- **증상**: `GetCascadeTrajectorySteps`에 `trajectoryId` 파라미터 → 500 "trajectory not found"
+- **원인**: 파라미터명이 `trajectoryId`가 아니라 **`cascadeId`**. 값은 `GetAllCascadeTrajectories.trajectorySummaries`의 맵 키(세션 ID)
+- **해결**: `{ cascadeId: sessionId }`로 호출 → 전체 step 배열 반환 성공
+- **주의**: `latestToolCallStep` 필드는 `GetAllCascadeTrajectories` 응답에 **존재하지 않음** (KI 오류)
+
+### [2026-03-08] Step 구조 — CORTEX_STEP_STATUS_WAITING 즉시 감지
+- **증상**: stall-based 감지(100초)가 너무 느림
+- **원인**: 이제 `GetCascadeTrajectorySteps`로 최신 step의 status를 직접 확인 가능
+- **해결**: stall 5초 후 step probe → `CORTEX_STEP_STATUS_WAITING` 확인 → 즉시 pending 생성
+- **Step 구조**: `{type: "CORTEX_STEP_TYPE_RUN_COMMAND", status: "CORTEX_STEP_STATUS_WAITING", metadata: {toolCall: {name, argumentsJson}}, runCommand, requestedInteraction}`
+- **주의**: 775-step 하드 리밋은 여전히 존재. 긴 세션에서는 fallback(40초) 사용
 
 ### [2026-03-08] Extension 재설치 안전성 — 자동 패치 메커니즘
 - **증상**: Antigravity 삭제 후 재설치 시 렌더러 스크립트가 동작 안 함
@@ -144,3 +151,16 @@
   2. `product.json` SHA256 체크섬 자동 업데이트
   3. HTTP bridge 서버 시작 + 결정론적 포트
 - **주의**: 패치 후 반드시 **Antigravity 풀 재시작** 필요 (Reload Window 불가). Extension VSIX만 설치하면 수동 패치 불필요
+
+### [2026-03-08] Response 파일 Race Condition — DOM Observer 승인 실패
+- **증상**: Discord에서 승인 → `[RESPONSE] renderer-handled approval` 로그 출력 → 실제 버튼 클릭 안 됨
+- **원인**: `processResponseFile` (파일 감시자)이 response 파일을 즉시 삭제 → renderer의 `pollResponse`가 HTTP `GET /response/:rid`로 조회 시 파일 이미 없음
+- **해결**: DOM observer 소스일 때는 response 파일을 삭제하지 않도록 수정. HTTP endpoint가 renderer에게 서빙한 후 삭제
+- **주의**: non-DOM (stall/step_probe relay)는 watcher에서 삭제해도 됨
+
+### [2026-03-08] Renderer 스크립트 소스 혼동 — 3곳의 코드
+- **증상**: `extension.ts`에 BTN-DUMP 추가 → Reload 2번 → 콘솔에 안 나옴
+- **원인**: renderer 코드가 **3곳**에 존재: (1) `extension.ts`의 `generateApprovalObserverScript()` (소스), (2) `ag-sdk-variet-gravity-bridge.js` (배포됨, Reload시 소스에서 재생성), (3) `workbench-jetski-agent.html` inline (HTML, JS파일과 중복로드 방지됨). 직접 JS파일 패치는 Reload시 소스에서 재생성되어 **덮어씌워짐**
+- **해결**: 항상 `extension.ts`의 `generateApprovalObserverScript()` 함수를 수정 → 컴파일 → 배포 → Reload
+- **주의**: HTML inline은 JS파일이 먼저 로드되어 `window.__agSDK` 가드에 의해 실행 안 됨. 실제 실행되는 것은 JS파일 경로의 스크립트
+