dropbox: shared-mode lookup uses case-sensitive name matching #9706

Summary

The Dropbox backend advertises case-insensitive filesystem behavior, but its special shared-folder and received-file lookup paths compare names with exact, case-sensitive Go string equality.

This is source-proven from the current implementation; I have not reproduced the mismatch against a live Dropbox remote.

Evidence

• backend/dropbox/dropbox.go:610-614: the backend declares CaseInsensitive: true.
• backend/dropbox/dropbox.go:951-965: findSharedFolder uses entry.(*fs.Dir).Remote() == name.
• backend/dropbox/dropbox.go:1033-1047: findSharedFile uses entry.(*Object).remote == name.
• These lookup functions manually search API results rather than resolving the requested name through Dropbox's normal path lookup.

Consequently, a listed shared item named Project is not found by these functions when requested as project, despite the backend's advertised case-insensitive behavior.

Impact

The user-visible impact has not been measured. The mismatch is limited to shared-folder and received-shared-file modes when the requested casing differs from the listed casing.

Question

Should these shared-mode lookup functions use the backend's case-insensitive name-matching contract instead of exact string equality?

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.