fix: clone workspace into repo-named subdirectory directly

Git clone with an explicit destination puts the working copy directly into
that directory; it does not create a repo-named subdirectory. The previous
change assumed the opposite, so workspaces ended up at
/data/working-copies/{workspace_id}/ with the repo contents mixed in,
causing a 500 when the expected repo-named subdirectory was missing.

- Build the target path as /data/working-copies/{workspace_id}/{repo_name}/
  and pass it directly to GitService.clone
- Remove stale directory detection and fallback logic that is no longer
  needed
- Keep diagnostic logging around git clone failures

Quality gates:
- pytest tests/unit: 219 passed
- mypy: clean on changed files

apps/.pi-map.md

@@ -4,10 +4,10 @@ dir: apps
 index: apps/.pi-map.index.md
 
 ## role
-This directory contains the main application entry points and executable modules for the project.
+Contains the main application entry points and executable modules for the project.
 ## files
 ## arch
-Modular application structure with separate deployable units, likely following a microservices or multi-app monorepo pattern where each subdirectory represents an independent application with its own configuration, dependencies, and lifecycle.
+Modular application structure with separate deployable units, likely following a monorepo pattern with independent app boundaries.
 ## tags
 -
 ## symbols