크라우니클라우드 B절 — 백엔드 없던 API 3종 신규 구현

개요

크라우니클라우드 사이드카(:9662)에 없던 API 3종(B-1/B-2/B-3)을 클라우드_서비스.한선에 신규 함수+라우팅으로 추가. 가드/게이트 큐 내부 로직은 동시 작업 중인 다른 에이전트 영역이라 손대지 않음.

B-1 POST /api/services/update — body {id,name,port,domain} → 변경보호 큐(service_update) 등록. 승인 시 서비스_적용_설정이 사용자서비스만 실제 필드 갱신(빈 필드는 기존값 보존), 시스템(registry) 서비스는 기록만+수동안내.
B-2 GET /api/services/stats?id= — PID를 lsof -tiTCP:<port> -sTCP:LISTEN으로 찾아 ps -o rss=(mem MB)·ps -o etime=(uptime) 실측. requests/errorRate는 카운터 인프라 없어 정직하게 null+note.
B-3 GET /api/services/logs?id=&lines= — id 화이트리스트(영숫자/_/-) 검증 후 logs/<id>.log 우선, 없으면 /tmp/<id>.err를 tail -n N(N≤40)으로. 둘 다 없으면 {"lines":[],"note":"로그 파일 없음"}.
신규 헬퍼: 서비스_경로시작, 서비스_쿼리값, 서비스_id검증, 서비스_id로포트, 서비스_사용자서비스필드갱신.
서비스적용(kind,payload)에 service_update 분기 추가.

STRICT 컴파일 0경고 (양쪽 모듈)
:9662 재기동 확인(자가치유, PID 신규)
B-1: POST update → {"queued":1,"pendingId":"pend_..."}. 실제 사용자서비스 생성→update→approve 흐름에서 가드통계 ok 3건 실측(create/update/delete)
B-2: GET stats?id=mail → {"requests":null,"errorRate":null,"mem":7,"uptime":"22:14","note":"..."}. id 누락 시 400 id_required
B-3: GET logs?id=mail&lines=5 → 실제 mail 서비스 로그 라인 반환
회귀: GET 9종 전부 200, 9611/9610 생존 확인

클라우드_가드.한선의 가드approve가 서비스적용(kind, what, payload) 3인자로 호출하는데, 서비스적용은 (kind, payload) 2인자로 정의돼 있음. 이 arity 불일치로 approve 경로에서 실제 서비스적용 내부의 서비스_적용_생성/설정/삭제가 감사장부에 _적용/_보류 로그를 전혀 남기지 않음(가드통계는 ok로 찍히지만 실제 적용 함수 로직이 의도대로 안 탐 — payload 자리에 what 문자열이 들어가 JSON 필드추출이 전부 빈값이 되는 것으로 추정). 실측: 보수테스트svc create→update→delete 큐 승인 후 감사장부에 system|... 라인이 하나도 없음. 가드/서비스 큐 부분 수리 중인 에이전트에게 인계 — 호출부(가드approve) 또는 서비스적용 시그니처 중 하나를 통일 필요.