Feat/forge check semantics and followup fixes (#2337)

* feat(protocol): add forge check presentation metadata

Expose optional rawStatus, isManual, and requiresAction fields while keeping older check payloads backward-compatible.

* fix(gitea): model Actions jobs as tasks

Gitea's /actions/tasks endpoint returns individual jobs rather than workflow runs. Preserve sibling tasks from the latest execution, avoid collapsing same-name jobs, and enrich blocked tasks with run-level approval metadata.

* feat(app): distinguish forge check presentation states

* fix(gitlab): preserve pipeline job semantics

* refactor(app): centralize forge check presentation policy

Use one canonical category order, count shape, visual policy, and translated copy mapping across sidebar, hover-card, PR-pane, and GitLab pipeline surfaces.

* refactor: consolidate forge check handling

* feat(forge): auto-attach pasted forge references

* docs(compat): correct forge rollout metadata

* refactor(forge): model check nuances as traits

* fix(forge): harden checks from branch review

Structural Gitea Actions shadow dedup by run id (verified upstream),
rerun grouping without workflow_id, shared trait/status constants and
Gitea state mapping in the protocol package, all cloud host aliases in
pasted-link matching, logged glab job-detail failures, concurrent
approvals/pipeline fetch, checks aggregate from the same pipeline as
the job list, and removal of the unread check-level rawStatus. The
released pipeline-level rawStatus is staged for removal under
COMPAT(pipelineRawStatus).

* fix(gitea): detect fork-PR Actions approval hold as action_required

gitea.com represents a fork PR awaiting Actions approval as a run in
status "waiting" with no tasks and pending shadow commit statuses; it
does not expose need_approval. The previous mapping only set
action_required from a task with blocked+need_approval, so the gate
never surfaced (0 tasks -> early return; need_approval absent). Detect
the hold from /actions/runs: a waiting/blocked run whose PR is
cross-repo (head.repo.id != base.repo.id), or one that does expose
need_approval (self-hosted). Tag the run's pending shadow statuses
action_required. Runs are only fetched when a pending shadow has no
covering task, keeping the common path at two requests. Verified live
against gitea.com fork PR (run 715170, waiting, cross-repo).

* fix(gitea): resolve cross-fork PRs by head sha

The current-PR matcher gated candidates on the checkout owner
(giteaHeadOwner === expectedHeadOwner), which excludes every fork PR:
its head carries the fork owner while the checkout is the base repo, so
a fork PR - the only shape that can be approval-held on Gitea - never
resolved and its checks never showed in-app. GitLab has no such gate
(it resolves fork MRs from the target project by source branch). Accept
a recent PR whose head sha equals the workspace head sha regardless of
owner; the sha is an unambiguous identity, so the anti-collision owner
gate still applies when no sha match is available. Verified live against
gitea.com fork PR #6 (resolves + renders action_required).

* fix: resolve forge rebase drift

* fix: type forge auto-attach boundary

* fix(i18n): add Korean check status copy

---------

Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>

docs/forge-providers.md

@@ -26,8 +26,9 @@ For forge `acme`, the expected end state is:
 3. **App modules** - a forge splits into a pure logic half and a view half so
    logic consumers (URL builders, merge-capability, native checks, and the
    Node-based e2e harness) never pull the client rendering stack:
-   - `packages/app/src/git/forges/acme.ts` - logic: `id`, optional `urlGrammar`,
-     optional `facts` (schema, merge-capability, native-check fallbacks). No
+   - `packages/app/src/git/forges/acme.ts` - logic: `id`, optional `urlGrammar`
+     (source links and pasted issue/change-request reference paths), optional
+     `facts` (schema, merge-capability, native-check fallbacks). No
      React/React-Native imports. Register in `CLIENT_FORGE_LOGIC_MODULES` in
      `packages/app/src/git/forges/index.ts`.
    - `packages/app/src/git/forges/acme.view.tsx` - view: `icon` (SVG component
@@ -57,8 +58,20 @@ schema-mismatched facts render neutrally instead of failing the whole message
 parse. This is the version-skew win: an old client can receive facts from a
 newer forge and still show the PR/MR in a neutral state.
 
+Check results keep a stable normalized `status` for aggregation and an optional
+open `traits: string[]` for composable forge-neutral refinements such as
+`manual`, `action_required`, and `warning`. Consumers ignore unknown traits and
+fall back to `status`; `rawStatus` preserves provider-native detail. Do not add
+provider vocabulary to the normalized status union. Producers and the
+presentation layer share the trait constants in
+`packages/protocol/src/check-traits.ts` — use those instead of string literals
+so classification and emission cannot drift apart.
+
 Shipped GitHub compatibility stays separate:
 
+- The forge compatibility layer first shipped in `v0.2.0-beta.1`. Its initial
+  six-month cleanup target is `2027-01-17`, after supported client and daemon
+  floors reach stable `v0.2.0`.
 - `status.github` remains accepted for released peers.
 - The server keeps the `COMPAT(forgeSpecific)` mirror that copies GitHub facts
   into `status.github` for older clients.
@@ -112,7 +125,7 @@ rendering stack:
 `acme.ts` exports a `ClientForgeLogicModule`:
 
 - `id`
-- optional `urlGrammar`
+- optional `urlGrammar` (including `referencePaths` for composer auto-attachment)
 - optional `facts` registration (schema, merge-capability, native-check fallbacks)
 
 `acme.view.tsx` exports a `ClientForgeViewModule`:
@@ -181,10 +194,27 @@ are stale, run `npm run build:server`.
   real shims tagged with `COMPAT(name)`.
 - Gitea-family facts use `forgeSpecific.forge === "gitea"` even when the
   top-level brand is Forgejo or Codeberg.
+- Gitea's legacy Actions task endpoint cannot filter by commit, may enforce a
+  page size below the requested limit, and omits rerun-attempt numbers. Walk a
+  bounded number of pages using `total_count` and filter locally. Preserve
+  ambiguous same-run tasks: display names are not stable job identities, so
+  name-based deduplication can hide a real failure.
+- A blocked Gitea Actions task is not necessarily manual: only add the
+  `action_required` trait when the matching run metadata reports
+  `need_approval`.
 - Brand icons are bundled React components, so they cannot come from protocol
   manifest data.
 - Source URL grammars are app-side because blob/tree path syntax is
   forge-specific. If a forge has no grammar, omit the "Open on ..." source link
   rather than constructing a wrong URL.
+- Pasted issue/change-request URL recognition is also app-side and registry
+  driven. Put the forge's route infixes in `urlGrammar.referencePaths`; the
+  neutral extractor matches the pasted host and full repository path against
+  the current remote before it invokes cwd-routed forge search. Do not add a
+  central forge switch or guess a self-hosted Gitea-family brand from URL shape.
 - GitLab pipeline status constants belong to the GitLab adapter/client module,
   not protocol.
+- GitLab `manual` jobs need `allow_failure` to distinguish optional gray jobs
+  (`manual`) from blocking jobs (`manual` plus `action_required`). A failed
+  allowed-failure job carries the `warning` trait, and `canceling` remains active
+  until GitLab reports a terminal status.