docs: runner deployment env, token persistence, and QA case accuracy

[cursor]

Summary

Documentation-only updates aligned with recent runner/Docker behavior and developer onboarding.

Docs added/updated

• deployment/compose/README.md — New Runner environment subsection: SEMAPHORE_WEB_ROOT vs unused SEMAPHORE_RUNNER_API_URL in the sample compose file, official image entrypoint (runner-wrapper), registration env vars (SEMAPHORE_RUNNER_REGISTRATION_TOKEN / _FILE), default SEMAPHORE_RUNNER_TOKEN_FILE under SEMAPHORE_DATA_PATH, persistence guidance, and mutual exclusion of SEMAPHORE_RUNNER_TOKEN vs SEMAPHORE_RUNNER_TOKEN_FILE.
• deployment/docker/README.md — New Runner image section summarizing runner-wrapper and pointing to the compose README for persistence/token details.
• test/test-cases/TC-027-runner-register.md — Expected results updated so token persistence matches real paths (config.json runner.token, token_file / env, or Docker --no-config default runner_token.txt).
• CONTRIBUTING.md — Dredd local steps: fixed duplicate step numbering / fence indentation for starting the server.

Codepaths covered

• deployment/docker/runner/runner-wrapper — defaults and registration branch.
• util/config.go — SEMAPHORE_WEB_ROOT, runner token / token file loading and panic when both token sources are set.
• services/runners/job_pool.go — URL construction from WebHost, writing the issued token to token_file when configured.

Knowledge gaps addressed

• Where the long-lived runner token is stored in Docker --no-config flows vs JSON config.
• Why /var/lib/semaphore (or an explicit SEMAPHORE_RUNNER_TOKEN_FILE) must persist across restarts.
• Clarification that SEMAPHORE_RUNNER_API_URL in the example compose stack is not consumed by the current runner binary.