fix(deployments): preserve and normalize VCS source roots - #13574

… into

`providerRootDirectory` reached the jobs-service through
`trim($subdir, '/')`, which strips slashes but not dots. `docs`, `docs/`
and `/docs` all canonicalized to `docs`, while `./docs` survived verbatim
as an artifact subdir naming a path segment that does not exist in the
extracted tree. `.` and `./` were worse: they collapsed to a non-empty
`.`, so the repository-root case emitted a subdir instead of omitting one.

Canonicalize on the consume side, in `Deployments::rootDirectory()`. Every
remote-source build funnels through `submit()`, so one choke point covers
new writes, rows already holding `./docs`, webhooks, duplicates and
templates without a migration.

Drop whole `.` segments rather than trimming the character. The builds
worker's `ltrim($path, '.')` turned `.github` into `github` — a silent
wrong-directory build — and left `../etc` traversal intact. Both worker
call sites now share the canonicalizer, and the jobs-service hand-off
passes the canonicalized value instead of re-reading the raw attribute,
which also closes a mismatch where the template push committed at a
space-stripped path but sent the space-bearing one.

`..` segments are dropped rather than resolved, so a subdir cannot escape
the tree it indexes into.

Dropping `..` segments made `docs/../x` build `docs/x`, which is neither
the directory the caller named nor the one POSIX would resolve — and if
both exist, the wrong application deploys with no warning. Resolving the
segment instead would let the subdir climb out of the tree it indexes
into.

Refuse the path instead. The failure is the owner's to fix, so it joins
the refused-variable-key case in carrying its reason into the build log
rather than a generic internal error.

Builds a function from './docs/nested/' — the form the console's
directory picker writes — over the Gitea suite, the only live-VCS suite
CI boots.

Covers both halves observably: the push-created deployment must execute
the nested entrypoint, and duplicating it must reach 'ready'. A duplicate
reads the root directory back off the source deployment, so a regression
that stops persisting it builds from the repository root, where the
auto-init README is the only file and no entrypoint exists.

…uild

The deployment response model does not expose providerRootDirectory, so
reading it off the body asserted on a key that is never returned.

Duplicating the push-created deployment proves the same thing through
behavior: the duplicate reads the root directory back off the deployment
it copies, so it only reaches 'ready' if the push persisted one. Also
deploy explicitly before pushing, so the nested entrypoint is observed
executing on a deployment the test activated rather than one it assumed
was active.