feat: implement ISSUE-WP-0005 connector mapping and scope alignment

Add MappingService (work_record_uuid ↔ external id), project/map CLI with
outward push-status, optional TaskSpec work_record fields, boundary-sync
policy, and packaging/capability framing cleanup. Mark WP-0005 finished.

AGENT_INTEGRATION.md

@@ -8,16 +8,17 @@ The **Issue Core** capability provides a standardized interface for autonomous c
 
 **Fleet note (2026-07-20):** Internal work originates as repo work records (ADR-001 / work-record canon), not as issue-core issues. Use this guide when an agent must project to or work inside a third-party tracker. See `INTENT.md` and `docs/uuid-external-id-mapping.md`.
 
-### Why Issue Tracking for Agent Coordination?
+### When to use a tracker (and when not to)
 
-Issue tracking provides a natural coordination mechanism for multi-agent software development:
+**Fleet claim/execute** runs on work records (repo files + state-hub), not on
+Forgejo by default. Use issue-core when:
 
-- **Task Distribution**: Issues represent discrete units of work that agents can claim and execute
-- **State Management**: Issue states (open, in_progress, closed) track progress across the team
-- **Communication Channel**: Comments enable inter-agent communication and human oversight
-- **Progress Visibility**: Labels, assignees, and milestones provide real-time project status
-- **Audit Trail**: Complete history of who did what and when
-- **Human Integration**: Human developers can seamlessly participate in agent-driven projects
+- A counterparty or OSS workflow lives in Gitea/GitHub/Jira
+- You need to **project or link** a work record (`issue project` / `issue map`)
+- You must update or comment on an **external** issue already in a tracker
+
+Do **not** treat issue-core as the org task board or as origin of intake/tasks.
+Findings → `kind: intake` + promotion; optional later projection.
 
 ## Current Status: Production-Ready with Manual Setup