fix: resolve SRS conflicts from batch verification analysis (CONFLICT-1~4)

Conflict Resolutions:
- CONFLICT-1 (High): Fix REQ-006 ownership scope — implement owner_user_id filtering
  * Change app/api/v1_assets.py: owner_user_id=None → owner_user_id=auth.user_id
  * Update docs/runtime-flows.md to reflect service-token owner-scoped portfolio filtering
  * Add regression test in tests/test_v1.py for ownership boundary

- CONFLICT-2 (Medium): Transition REQ-001/002/003 to Implemented
  * REQ-001: local-db-validation-scenarios (via confirm-req-implemented bat-007)
  * REQ-002: alembic-runtime-schema-ownership (via confirm-req-implemented bat-007)
  * REQ-003: local-db-operations-runbook-and-baseline-updates (via confirm-req-implemented bat-007)
  * Update docs/srs/index.md with status transitions

- CONFLICT-3 (Low): Document REQ-012 rotate lifecycle
  * Add rotate lifecycle notes to REQ-012 (change-req req-012)
  * Clarify runtime_id change behavior and trex-basic reconnection requirements

- CONFLICT-4 (Low): Clarify REQ-005 AC-2 endpoint path
  * Change REQ-005 AC-2: 'POST /auth/tokens or equivalent' → 'POST /auth/service-tokens'
  * Update docs/srs/index.md change log with change-req entries

Documentation Updates:
- Update BAT-001 verification status with conflict resolution evidence
- Update release rel-001 with verified status confirmation
- Add change log entries for all conflict resolutions with dates and references

Testing:
- Add ownership boundary test to test_v1.py
- Verify filter works with auth.user_id context

docs/srs/Interface/req-005_service-token-runtime-id-issuance.md

@@ -16,7 +16,7 @@
 
 ## Acceptance Criteria
 1. Given `pfhub service-token issue <name> --user <username>` 실행 시, When 발급이 성공하면, Then 출력에 token 문자열과 runtime_id가 모두 포함되어야 한다.
-2. Given API 엔드포인트(POST /auth/tokens 또는 동등 경로)로 service-token 발급 시, When 성공 응답을 받으면, Then 응답 JSON에 token과 runtime_id가 포함되어야 한다.
+2. Given API 엔드포인트(POST /auth/service-tokens)로 service-token 발급 시, When 성공 응답을 받으면, Then 응답 JSON에 token과 runtime_id가 포함되어야 한다.
 3. Given runtime_id가 발급된 service-token으로 GET /v1/user_info를 호출하면, Then 응답의 runtime_id가 발급 시 생성된 값과 동일해야 한다.
 4. Given 동일 사용자에 대해 두 번의 service-token 발급을 수행하면, Then 각각 다른 runtime_id가 반환되어야 한다.
 5. Given auth_tokens 테이블을 직접 조회하면, Then 발급된 service-token 행에 runtime_id 값이 저장되어 있어야 한다.
@@ -34,6 +34,47 @@
 
 ## Change Log
 
+### CHG-20260511-02
+- Date: 2026-05-11
+- Author: repository-maintainers
+
+#### Change Summary
+- REQ-005 AC-2의 API 경로를 실제 구현 경로인 `POST /auth/service-tokens`로 명확화
+
+#### Intent
+- CONFLICT-4 분석 결과를 반영해 "POST /auth/tokens 또는 동등 경로"라는 모호한 표현을 제거하고, BAT-001 verification과 runtime flow에 이미 반영된 실제 엔드포인트로 REQ를 정렬한다.
+
+#### Acceptance Criteria Delta
+- Added:
+  - none
+- Updated:
+  - AC-2: API 발급 경로를 `POST /auth/service-tokens`로 구체화
+- Removed:
+  - none
+
+#### Impacted Area Delta
+- Docs:
+  - `docs/srs/Interface/req-005_service-token-runtime-id-issuance.md`: AC-2 경로 문구 명확화
+- Modules:
+  - none
+- Tests:
+  - none
+
+#### Delivery Trace Delta
+- Batches:
+  - BAT-001 (release-candidate) — verification evidence는 이미 `POST /auth/service-tokens` 기준으로 정렬되어 있어 추가 재검증은 불필요
+- Releases:
+  - REL-001 (draft) — release scope 문서도 동일 경로를 사용 중이라 추가 수정 없음
+
+#### Revalidation Impact
+- Reverification Needed: no
+- Existing Implementation Invalidated: no
+- Status Recommendation: keep-current
+- Follow-up Action: none
+
+#### Validation Plan
+- REQ-005 AC-2, BAT-001 verification evidence, runtime-flows.md의 API 경로가 모두 `POST /auth/service-tokens`로 일치하는지 코드 리뷰로 확인
+
 ### CHG-20260511-01
 - Date: 2026-05-11
 - Author: repository-maintainers