feat(ui): allow free-text path input when selecting workspace folder

[pascalandr]

Summary

• Make the existing path input in DirectoryBrowserDialog discoverable by adding a translated placeholder and aria-label.
• Add an Enter path manually link next to the Browse button on the folder selection view, so the in-app dialog is reachable on every platform.
• Open the dialog at the most recent folder instead of the server default, so users who work outside their home directory don't have to navigate back every time.
• Add the matching i18n keys across all 7 supported locales.
• Accept an optional comma-separated list in --workspace-roots so users with projects in several unrelated folders don't have to run multiple server instances.

Why

The in-app DirectoryBrowserDialog already had a text field for the current path, but it was effectively unreachable and always started at the server's single root.

1. The input now has a placeholder + aria-label and is reachable via an Enter path manually link.
2. The dialog starts at the most recent folder.

What changed

UI

• packages/ui/src/components/folder-selection-view.tsx: added an Enter path manually link below the Browse button that opens DirectoryBrowserDialog, and passes initialPath={folders()[0]?.path} so the dialog opens on the most recent folder.
• packages/ui/src/components/directory-browser-dialog.tsx: new optional initialPath prop consumed by initialize(); the current-folder <input> now has placeholder and aria-label i18n strings.
• packages/ui/src/lib/i18n/messages/*/filesystem.ts / folderSelection.ts: 3 new keys across all 7 locales.

Server

• packages/server/src/filesystem/browser.ts + api-types.ts + index.ts: --workspace-roots accepts multiple comma-separated paths. When more than one is given, the picker shows them side by side at the top level (same mechanism already used for Windows drives). Omitting the flag keeps the current single-root behaviour unchanged.

Validation

• npm run build --workspace @codenomad/ui — typecheck + Vite build pass, PWA generated.
• npm run build --workspace @neuralnomads/codenomad — server build passes.

Closes #349
Closes #312

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Gatekeeper review for the latest PR state.

What I reviewed

• I reviewed the current PR diff against origin/dev.
• I focused on regressions and implementation quality in the new multi-root filesystem behavior, the folder selection dialog changes, and the related filesystem picker updates.
• Assumption: the intent is to review the current branch state only, not to request code changes from me in this run.

Findings

1. High: FileSystemBrowserDialog still normalizes absolute paths as if they were relative, which breaks navigation once the server returns absolute entry paths.

• File: packages/ui/src/components/filesystem-browser-dialog.tsx:12-24, 90-116, 193-197
• normalizeEntryPath() strips leading /, and fetchDirectory() uses that normalized value as the request path sent to /api/filesystem.
• In multi-root mode, entries are now absolute. Clicking a root or child like /work/foo becomes work/foo on the wire, so the backend resolves the wrong location or rejects it.
• This is not dead code: FileSystemBrowserDialog is used by packages/ui/src/components/opencode-binary-selector.tsx:344-351, so binary selection will regress under multi-root configuration.
• I would not merge before fixing this.

2. Medium: the top-level multi-root listing can produce indistinguishable entries for different roots.

• File: packages/server/src/filesystem/browser.ts:218-224
• The label is path.basename(rootPath) || rootPath. If users configure roots like /work/client/app and /archive/app, both render as app in the roots view.
• That makes the new picker ambiguous right at the entry point.
• Better implementation: either show the full path in the label/subtitle, or detect duplicate basenames and disambiguate only when needed.

3. Medium: CLI behavior and help text disagree for --workspace-roots.

• File: packages/server/src/index.ts:94-97, 174-178
• The option description says these are "absolute paths", but parsing accepts any string and later path.resolve() silently converts relative values based on the server process CWD.
• That makes the feature less predictable and can expose a broader area than the operator intended.
• Better implementation: validate absolute paths up front and fail fast, or relax the help text to match the actual behavior.

Verification

• I attempted the builds claimed in the PR description:
  • npm run build --workspace @codenomad/ui
  • npm run build --workspace @neuralnomads/codenomad
• I could not complete build verification in this workspace because the environment is missing vite (ERR_MODULE_NOT_FOUND: Cannot find package 'vite'). So I cannot confirm the claimed build status from this run.

Verdict

• Request changes.
• The FileSystemBrowserDialog absolute-path regression is a merge blocker.
• The other two points are implementation-quality issues that should be addressed or consciously accepted before merge.

--
Yours,
CodeNomadBot

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Updated gatekeeper review for the latest PR state.

What I understood

• You want a fresh gatekeeper pass on the current PR head: check for regressions, look for better implementations, and be strict about merge quality.
• Assumption: this is a review-only request for the latest branch state.

Result

• I re-checked the current diff against origin/dev.
• The previous blocker in packages/ui/src/components/filesystem-browser-dialog.tsx is fixed: absolute paths are now preserved and the dialog correctly handles roots views.
• The earlier ambiguity in duplicate multi-root labels is also addressed.
• I do not see any remaining merge-blocking regressions in the current PR state.

Remaining note

1. Low: one API comment is now inaccurate relative to the implementation.

• File: packages/server/src/api-types.ts:198-205
• The comment says FileSystemCreateFolderResponse.path is absolute for "newly-created restricted folders".
• In the actual single-root restricted implementation, createFolder() still returns a relative path: packages/server/src/filesystem/browser.ts:112-119.
• This is documentation drift, not a runtime bug, so I would not block merge on it.

Verification

• I attempted the same build checks again from this workspace:
  • npm run build --workspace @codenomad/ui
  • npm run build --workspace @neuralnomads/codenomad
• I still cannot independently verify them here because the environment is missing vite (ERR_MODULE_NOT_FOUND: Cannot find package 'vite').

Verdict

• No blocking findings in the latest PR state.
• The only remaining issue I found is a low-severity type comment mismatch.

--
Yours,
CodeNomadBot

[pascalandr]

comment corrected