feat(ui): add file tab path copying

[pascalandr]

Fixes #328

Summary

• add a simple file filter in the Files tab
• add a per-row Copy path action for the current folder listing
• show localized success/error toasts for path copy actions

Why

The Files tab already exposes the file list, but there was no fast way to reuse a file path in a prompt.

This change adds the smallest useful path-copy workflow directly where users browse files.

What Changed

• packages/ui/src/components/instance/shell/right-panel/tabs/FilesTab.tsx
  • added a local filter input for the current folder
  • added a Copy path action on file rows
  • fixed the initial loading state so the empty-folder message does not flash before the first list load completes
• packages/ui/src/lib/i18n/messages/*/instance.ts
  • added strings for file filtering, copy-path labels, and copy toasts

Validation

• npm run build --workspace @codenomad/ui

[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

• Diff against origin/dev, focused on FilesTab.tsx and the new i18n keys
• The current thread request as a PR gatekeeper pass for regressions and better implementations

Findings

1. Blocking: failed folder loads now render an incorrect empty-state message instead of just the error.
   • File: packages/ui/src/components/instance/shell/right-panel/tabs/FilesTab.tsx:196
   • Why this matters: the new fallback shows listEmpty / search.empty whenever filtered.length === 0 and initialListLoading is false. But in RightPanel, failed list requests set browserError and also browserEntries([]) (packages/ui/src/components/instance/shell/right-panel/RightPanel.tsx:492-495). That means any folder-list failure now tells the user both that there was an error in the header and that there are “No files in this folder” in the body. The body message is false and masks the actual state.
   • Recommended fix: gate the empty-state fallback behind !props.browserError(), or render the error state in the list body with higher priority than the empty/filter-empty message.

Non-blocking implementation note

• FilesTab.tsx:196 also shows search.empty even though the parent .. row is still visible. That is not a blocker, but if you want the message to be literal, either exclude the parent row from the visual result set entirely when filtering, or adjust the wording to mean “No matching items in this folder listing”.

Validation

• I attempted npm run build --workspace @codenomad/ui, but this workspace does not currently have the build dependency graph available in the runner (ERR_MODULE_NOT_FOUND: Cannot find package 'vite'). So I could not complete a local build verification from this environment.

Verdict

• Not ready to merge as-is because of the incorrect empty-state behavior on file-list load failures.

--
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

• Re-run the PR gatekeeper pass against the current branch state, focusing on regressions and implementation quality.
• Assumption: the latest diff on codenomad/pr-353 is the state intended for review.

Findings

• No blocking findings in the current patch.

Non-blocking note

1. packages/ui/src/components/instance/shell/right-panel/tabs/FilesTab.tsx:196
   • The previous blocking issue is fixed: failed folder loads now correctly prioritize the error state instead of showing a false empty-state message.
   • Minor polish only: when a filter has no matches, the UI can still show the .. parent row above the search.empty message. That wording is slightly imprecise because the list is not visually empty. If desired, either keep the parent row out of the filtered result experience or tweak the copy to mean “no matching files in this folder”.

Validation

• I re-checked the latest diff against origin/dev.
• I could not complete a local build in this runner because the workspace environment is missing vite (ERR_MODULE_NOT_FOUND: Cannot find package 'vite'). So there is still an environment-level validation gap here rather than a code-specific failure.

Verdict

• Gatekeeper status: ready to merge from the code review side, with the build still unverified in this environment.

--
Yours,
CodeNomadBot