trusted-workload-launcher: address PR #97 review

- Shorten root README Details row
- Document line-oriented config and call-a-script pattern for multi-line
- Drop non-ASCII (em-dash) from launcher script comments and log line
- Rewrite VERIFY.md: lead with 5-step quick path, add Mermaid diagrams,
  drop TIP terminology, promote compose-mounted config as the recommended
  production path, rewrite source provenance around Sigstore attestation
  (not bit-for-bit reproducibility), and re-anchor the smoke transcript
  on compose-hash <-> sha256(app_compose) binding from a real production
  Phala smoke (CVM twl-cfg-smoke-20260511-180207, deleted after capture).

Author: h4x3rotab

README.md

@@ -231,7 +231,7 @@ Implementation details and infrastructure patterns.
 | Example | Description |
 |---------|-------------|
 | [launcher](./launcher) | Generic launcher pattern for Docker Compose apps (auto-update) |
-| [trusted-workload-launcher](./trusted-workload-launcher) | Tiny auditable launcher image that fetches a workload at a full upstream Git commit SHA — opposite trust posture to `launcher/` (no auto-update). The launcher image digest attests the launcher itself; the workload pin lives in a config file that must be attested via dstack `compose_hash`/`config_id` or baked into a derived image |
+| [trusted-workload-launcher](./trusted-workload-launcher) | Auditable launcher that pins a workload to a full upstream Git commit SHA (no auto-update). |
 | [prelaunch-script](./prelaunch-script) | Pre-launch script patterns (Phala Cloud) |
 | [private-docker-image-deployment](./private-docker-image-deployment) | Using private Docker registries |
 | [attestation/rtmr3-based](./attestation/rtmr3-based) | RTMR3-based attestation (legacy) |

trusted-workload-launcher/README.md

@@ -126,6 +126,23 @@ shell expansion in the parse step.
 | `REPO_SUBDIR` | Relative directory inside the repo to `cd` into before `INSTALL_CMD` and `RUN_CMD`. Must not be absolute and must not contain `..`. |
 | `CHILD_ENV_FILE` | Path to a separate env file. Each `KEY=VALUE` line is `export`ed into the environment seen by `INSTALL_CMD` and `RUN_CMD`. The file is parsed line-by-line just like the main config (not sourced). |
 
+### Multi-line install or run logic
+
+`INSTALL_CMD` and `RUN_CMD` are single-line shell strings — the config is
+line-oriented and the launcher does not implement multi-line value parsing.
+This is intentional: a config that "almost" parses a multi-line script is a
+trust hazard. If you need more than one command, put a script in the
+workload repo at the pinned commit (e.g. `scripts/install.sh`,
+`scripts/run.sh`) and call it:
+
+```
+INSTALL_CMD=./scripts/install.sh
+RUN_CMD=./scripts/run.sh
+```
+
+The script then lives at the same pinned `COMMIT_SHA` as the workload, so
+its bytes are covered by the same audit.
+
 ### What the launcher will and will not do
 
 * Will: clone fresh if `WORK_DIR` is empty; reuse the existing clone otherwise