Provide Local Folder Name Logic Documentation

As mentioned in SUPNXP-38702 (see full description below), the local folder (re)naming isn't clear.

Some documentation should be written to detail this process.

---------------------------------------------------------------------------------------------------

Summary:
Unable to deduce and need proper documentation around the local folder name logic and behavior.

Details:
We are noticing inconsistencies in where sometimes a sync’d folder contains the folder name and the former two parent folders of the remote DAM in the format enclosed in hard brackets below.
[ parent folder - parent folder - actual folder ]
Then sometimes after some time a folder may mysteriously rename to the just the folder name without any parent folder referenced in the file name.
[ actual folder ]

Steps to Reproduce:
(Assuming Nuxeo Drive is setup.)
1. Create and Name a deeply nested folder structure in a OneDAM workspace .
e.g. P&D/Workspaces/Cats/Do/They/Really/Have/Nine Lives/and-a-bunch-of-files.ext

2. Sync “Nine Live”

3. Create and Name another deeply nested folder structure in a OneDAM workspace.
e.g. P&D/Workspaces/Dogs/All/These/Go/To/Heaven/and-a-bunch-of-files.ext

4. Sync “Heaven”

5. Create and Name another less nested folder structure in a OneDAM workspace.
e.g. P&D/Workspaces/Wolverines/Smell/and-a-bunch-of-files.ext

6. Sync “of Smell”

7. This is not always consistent but come back after some time and you might notice that one of the folders, possibly Smell renames from [ Workspaces - Wolverine - Smell ] to just [ Smell ]

Additional Concerns/Considerations:
This type of renaming of folders could impact applications. For example if one were editing a file in Sublime Text and some parent folder was renamed, the application may ask user to save a new copy of the file.

Inquiry:
Both Engineering and Tenant Teams would benefit from documentation on what is expected behavior and logic.