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