fix(desktop): offer to restore an archived project when re-adding its directory

[faga295]

Summary

Fixes #4935

When the Add project flow picks a directory that belongs to an archived project, it now returns an { ok: false, reason: 'archived', projectId } result instead of failing opaquely. All three entry points then show a confirm dialog offering to restore the archived project in place, after which the add/selection succeeds:

• app shell project actions (app-shell-project-actions.ts)
• task-entry workspace picker (use-task-entry-controller.ts, new confirm port with toast-confirm default)
• projects settings page

Also included:

• new projects.restoreProject preload bridge method
• error logging in the runtime-host project/skill catalog coordinators so commit_outcome_unknown mutation failures are visible in logs (uses generalizedErrorMessage to avoid leaking paths)
• localized copy for the restore dialog (en/zh)

Test plan

• npm run build:test passes
• node --test on the touched suites (app-shell-project-actions, project-management-service, task-entry-controller, use-project-context): 28/28 pass, including new cases covering the archived → restore → select flow

[Astro-Han]

I reviewed this PR at head 9a27002c (17 files, +262/−21) against base 2310035a.

Gate is not ready — two blockers:

1. Protocol epoch regression on merge. The head's packages/runtime-host/src/protocol/index.ts declares RUNTIME_HOST_COMPATIBILITY_EPOCH = 112, while the live base and current main are at 121 (nine versions newer). The branch forked from epoch-112-era main and has never been rebased: the merge-base (cbeb1a93c) is at 112, the head's first parent is that same old commit, and the branch is 62 commits behind main. The PR makes no protocol change, so there is no epoch bump in the diff — but merging this head would regress the protocol epoch from 121 to 112. Please rebase onto the current main (no epoch bump is needed afterwards, since the protocol is untouched) and push the new head for re-review.
2. CI has not run on this head. Only the label check exists; the test workflow was never scheduled (first-contributor approval gate). The merge gate cannot close until test runs green on the exact head.

Code review (the feature itself):

• The Add-project flow now detects an archived project after catalog registration and returns { ok: false, reason: 'archived', projectId } instead of failing opaquely; all three entry points (app-shell project actions, task-entry workspace picker, projects settings page) present a confirm dialog and restore through the existing projects:restore bridge and projectManagement.restore path.
• toast.confirm is a pre-existing @maka/ui API, and the type wiring is sound; copy covers en/zh-CN/zh-TW for the dialog keys.
• Tests cover the archived detection, the confirm → restore → select flow, and restore-failure retry (pending state released).
• The added runtime-host error logging uses generalizedErrorMessage for the summary; one recorded P3: the raw error object is also passed as the second console.error argument, which may still carry paths in the main-process log (not a user-facing surface, acceptable).

No P0–P2 code findings. This is a bugfix for #4935 and the direction is right, but the current head must not be merged: rebase onto current main and get CI approved/run first.

---

Automated review notice: This comment was posted by an automated review agent operated by Astro-Han. It is not an independent human review and does not replace one.

[Astro-Han]

Thanks for reusing the existing restore operation. Two normal entry paths still fail the intended restore-and-use contract: AppShell does not commit the selected project, and Settings waits for confirmation inside an Astryx async transition. Details inline. Please keep the repair at the existing selection and interaction boundaries rather than adding another restore coordinator.

中文

复用已有restore操作的方向正确，但AppShell没有提交项目选择，Settings则在Astryx异步transition内等待确认，两个入口都未完成预期操作。建议修在已有选择/交互接缝，不新增恢复协调器。

AI-assisted review at 9669fcce8. The coordinating Codex agent independently reproduced the Button/ToastProvider behavior in a browser through DOM-dispatched actions and checked the AppShell/Host selection calls; this was a component integration probe, not full-app acceptance.