fix(services/dropbox): preserve list semantics

[suyanhanx]

Which issue does this PR close?

N/A. This fix came out of a service review pass and I couldn't find a dedicated Dropbox issue for it.

Rationale for this change

Dropbox listing was building entries from entry.name, which only contains the basename. That dropped operator-relative parent paths for nested entries and made exact-directory list requests behave too much like raw Dropbox prefix queries.

What changes are included in this PR?

• add a lightweight metadata check before Dropbox list so exact directory paths can be distinguished from file or prefix-style queries
• build list entries from Dropbox path_display relative to the operator root instead of from the basename alone
• emit the queried directory itself on the first list page to match OpenDAL list semantics
• share Dropbox metadata parsing across stat, list, and write so etag, version, and modified time stay consistent
• add unit tests for nested path preservation and directory normalization

Are there any user-facing changes?

Users of the Dropbox service should now get correct relative paths from list, especially for nested recursive listings and exact-directory queries.

AI Usage Statement

Built with Codex (GPT-5).