Remediation dialog hides the real lockfile-resolution error

[alamb-hex]

When resolveLockfile fails, update/route.ts:85 returns:

return { status: 500, body: { success: false, error: `Lockfile resolution (${resolutionMode}) failed`, resolution } };

The resolution object carries resolution.error and resolution.actions[], which contain the actual package-manager output. But remediation-dialog.tsx:308 renders only outcome.error — the generic wrapper string.

Result: every failure, regardless of cause, shows the identical message Lockfile resolution (clean-slate) failed. The diagnosis is present in the response payload and simply never displayed.

Real-world impact

Repeated remediation attempts on do868.com all failed with that one line. The actual cause was in resolution.actions:

WARN Failed to replace env in config: ${GITHUB_TOKEN}
ERR_PNPM_FETCH_404 GET https://registry.npmjs.org/@do868%2Fshared: Not Found
No authorization header was set for the request.

Diagnosing it required reproducing the install by hand from the CLI.

Fix

Render resolution.actions[] (and resolution.error) in the failure branch of the dialog — the log-tail treatment already used by renderInstallLogTail() would suit it.

Notes

Small change, high leverage — it would have made this self-diagnosing. Should land before the other two issues in this set.

[alamb-hex]

Fixed on branch fix/install-env-and-lockfile-rollback (33a81c0), not yet pushed.

Verified end-to-end against do868-com with the server launched without the credential:

• preflight now returns .npmrc references unset variable(s): GITHUB_TOKEN instead of a 404 on @do868/shared
• clean-slate refuses before deleting: lock file md5 and node_modules both unchanged across the failed call
• with the credential present, all three do868 projects return success: true

437 tests passing, tsc --noEmit clean, no new lint diagnostics.