Support the Dynamic WebDAV root in `b2c webdav` commands

What would you like?

Add dynamic to the list of WebDAV roots accepted by b2c webdav commands
(ls, get, put, mkdir, rm, zip, unzip), so that the per-site
Dynamic file location can be managed with the CLI:

https://<instance>/on/demandware.servlet/webdav/Sites/Dynamic/<site-id>/...

Today -r, --root only accepts
impex|temp|cartridges|realmdata|catalogs|libraries|static|logs|securitylogs,
so the Dynamic location is not reachable at all. The only workarounds are raw
curl with PUT/PROPFIND/MKCOL/DELETE, or mounting the WebDAV share
manually from Business Manager.

Since Dynamic is scoped per site, the command would need a site to resolve the
path — either an explicit flag (e.g. --site-id) or by requiring the site id
as the first path segment:

b2c webdav ls  --root=dynamic --site-id=MySite mockData
b2c webdav put --root=dynamic --site-id=MySite ./mock.vm mockData/

Why?

The Dynamic location holds data that is deliberately not part of a code
version, and some Script API features can only read from there:

• dw.template.Velocity#renderTemplate() resolves a template file name in
  the Dynamic WebDAV location for the current site, and files included from an
  ISML template via #parse / #include are always resolved in Dynamic with
  no way to pass an absolute path
  (see dw.template.Velocity in the Script API reference).
• Consequently, Velocity templates used for mock/stub service responses,
  and other site-scoped data files, must live under
  Sites/Dynamic/<site-id>/, not under cartridge/templates/.

Our use case: we drive local/sandbox testing by swapping mock service responses
implemented as .vm templates rendered through Velocity.renderTemplate().
These files must be updated independently of code deployments — that is the
whole point of keeping them outside the code version — but every update
currently falls outside the CLI, which breaks otherwise fully scripted setup
and CI flows. Being able to list, upload, download, and remove these files with
b2c webdav would make the Dynamic location manageable with the same tooling
and credential resolution (dw.json / SFCC_* / b2c setup inspect) as every
other WebDAV root.

Start at the b2c webdav command implementation and its --root validation, then trace how existing roots resolve paths and how command tests cover ls, get, put, mkdir, rm, zip, and unzip. Choose one site-id input convention, add dynamic support across those commands, and verify the site-scoped path behavior and credential handling with tests.