refactor(client): share filesystem browse navigation - #4797

💭 Looking at this PR, it's moving filesystem browse navigation logic into a shared module within client-runtime. I need to check whether the new functions being added follow Effect service conventions. The main file introduces several functions like getFilesystemBrowsePath, filterFilesystemBrowseEntries, and createBrowseNavigationCoordinator that handle the navigation logic. Checking the imports, the file brings in types and constants from @t3tools/contracts using named imports, which aligns with the convention for external packages. But looking more closely, these appear to be pure helper functions rather than actual Effect services, so I should examine the full file and how it relates to the existing projects.ts helpers to understand the actual refactoring being done. Looking at the imports and structure, this PR is just moving pure utility functions and the Atom factory into a shared module—there are no Effect services being created or refactored here. The conventions about Context.Service and layers don't apply since these are just helper functions, not service definitions. I'm checking whether the consuming files like CommandPalette and AddProjectScreen violate any Effect conventions, but they're React components, not Effect services, so the refactor appears clean. Let me verify once more that there's nothing in this PR that breaks Effect conventions—the changes are purely functional with no service definitions or layer violations. I'm confident there are no violations here. I'll set the state to success and put "All clear" in the summary to honor the instruction within the JSON format requirement.