Static import invokes generated DLA scripts under a nonexistent /wordpress prefix

## Problem

A generated static-site import can capture and convert successfully, then install zero candidate pages because the acceptance/import flow invokes generated scripts at:

```text
/wordpress/.dla-scripts/...
```

The Studio site exposes those generated scripts at:

```text
/.dla-scripts/...
```

Removing the hard-coded `/wordpress` prefix allows the existing generated scripts to run and the pages to install. Without that runtime override, browser acceptance cannot start even though the conversion artifacts are complete.

## Acceptance

- Resolve generated script paths from the active WordPress/site root rather than assuming a `/wordpress` subdirectory.
- Support both Studio layouts where WordPress is the workspace root and environments that intentionally mount it under a subdirectory.
- Fail before import with a typed diagnostic containing the resolved script path when it does not exist.
- Add an end-to-end fixture that captures, converts, imports, and verifies at least one installed page in a root-mounted Studio site.
- Preserve current paths for explicitly subdirectory-mounted runtimes.

## AI assistance

OpenAI GPT-5.6 Sol via OpenCode general coding and acceptance agents reproduced the zero-page import, isolated the generated-script path mismatch, and drafted this report. Chris Huber reviewed and remains responsible.

Start in the acceptance/import flow that constructs generated DLA script paths and trace how the active WordPress/site root is resolved. Reproduce the root-mounted Studio case, then add the requested end-to-end fixture and verify both root and explicitly subdirectory-mounted layouts, including the typed missing-path diagnostic.

Written by the indexing model from the issue text.