feat: import release commits from repository api

docs/FEATURES/release-communications.md

@@ -161,8 +161,11 @@ The back office should support:
 - publish entries
 - archive published entries
 - list imported commits
+- fetch latest commits from the configured repository API
 - filter commits by communication status
 - search commits by subject, SHA, author, or linked update
+- select commits and copy SHA/subject details for external summarization
+- create a draft update entry from selected commits, then link those commits to the entry
 - link one or more commits to an update entry
 - unlink a commit from an update entry
 - mark commits as internal-only
@@ -170,7 +173,7 @@ The back office should support:
 - show an "unreviewed commits" count
 - show linked commits on update detail pages
 
-The first implementation can import commits through an explicit submitted payload. Repository-backed import must use configured repository connection settings; the application must not assume the deployed filesystem contains a `.git` directory.
+The first implementation can import commits through either an explicit submitted payload or a configured repository connection. Repository-backed import uses the configured HTTPS repository URL and access token through a Gitea-compatible REST API; the application must not assume the deployed filesystem contains a `.git` directory.
 
 ## Commit Import Rules
 
@@ -181,7 +184,7 @@ The first implementation can import commits through an explicit submitted payloa
 - A release update can link many commits.
 - Imported commits default to `Unreviewed`.
 - Merge commits may be imported but can be marked `Ignored`.
-- Commit import should support a bounded range, such as `sinceSha..untilSha` or `sinceDate..untilDate`.
+- Commit import should support a bounded range, such as `sinceSha..untilSha` or `sinceDate..untilDate`, when the configured repository API supports it.
 - Repository URL and access credentials belong in configuration/secrets, not hard-coded docs or code.
 
 ## Email Digest

docs/TASKS/release-communications/003-developer-commit-reconciliation.md

@@ -26,6 +26,8 @@ Add the developer back-office workflow for importing shipped commits and matchin
 - Add developer-only frontend screens:
   - `/app/developer/release-commits`
   - linked commits on `/app/developer/updates/:id`
+- Add repository-backed import from configured HTTPS repository settings.
+- Add a selected-commit workflow to copy commit SHA/details and create a draft update entry linked to those commits.
 - Support filters for:
   - communication status
   - linked update
@@ -54,6 +56,7 @@ Add the developer back-office workflow for importing shipped commits and matchin
 - A release update can have many linked commits.
 - Imported commits default to `Unreviewed`.
 - Import must use either a submitted commit payload or configured repository connection settings. Do not discover or read a local `.git` directory from the deployed app filesystem.
+- Repository import currently targets a Gitea-compatible REST API derived from the configured repository URL.
 - Repository URL and access credentials must come from configuration/secrets.
 - Do not generate user-facing update entries automatically from commits.
 
@@ -69,7 +72,10 @@ npm run build
 ## Done When
 
 - [x] Developers can import commits idempotently.
+- [x] Developers can fetch commits from the configured repository API.
 - [x] Developers can list and filter imported commits.
+- [x] Developers can select commits and copy SHA/details for external summarization.
+- [x] Developers can create a draft update entry from selected commits.
 - [x] Developers can link commits to release updates.
 - [x] Developers can unlink commits.
 - [x] Developers can mark commits internal-only.