dropbox: deep shared-folder roots use the parent path as the folder name #9705

Summary

When shared_folders is enabled with a root deeper than one child below the shared folder, NewFs uses the complete parent path as the shared-folder lookup name. The documented behavior says that only the first path component identifies the shared folder.

This is source-proven from the current control flow; I have not reproduced it against a live Dropbox remote.

Evidence

• The shared_folders option documentation says that the first path component is interpreted as the shared-folder name.
• backend/dropbox/dropbox.go:630-642: NewFs derives the lookup value with path.Dir(f.root) and passes it to findSharedFolder.
• For SharedFolder/subdir/file, this produces SharedFolder/subdir rather than SharedFolder.
• backend/dropbox/dropbox.go:951-965: findSharedFolder compares its argument with each individual shared folder's Remote() name and returns fs.ErrorDirNotFound when none matches.

For example:

SharedFolder                 -> lookup "SharedFolder"
SharedFolder/subdir          -> lookup "SharedFolder"
SharedFolder/subdir/deeper   -> lookup "SharedFolder/subdir"

The third lookup cannot match an individual shared-folder name.

Impact

The impact has not been measured against a live remote. Source control flow indicates that configuring a sufficiently deep root below a shared folder can fail during NewFs even though the shared folder exists.

Question

Should the shared-folder lookup extract only the first component of f.root and preserve the remaining components as the root inside the mounted folder?

I checked all relevant issues, comments, pull requests, and forum threads; this report is not a duplicate.

Involvement

I am reporting this finding only and am not currently proposing a pull request.

Investigated extensively with GPT-5.6 Sol (xhigh reasoning effort), using Oh My Pi as the agent framework.