Release 1.1.3 with game window and Gamescope lifecycle fixes

release/README.md

@@ -3,11 +3,12 @@
 Manual publication mode is currently active. Build a complete local package with:
 
 ```text
-./scripts/release.sh stable 1.8.0
-./scripts/release.sh prerelease 1.9.0-beta.1
+SIGNING_KEY_PATH="${XDG_CONFIG_HOME:-$HOME/.config}/pristontale-eu/release/launcher-update-private.pem"
+PTLINUX_SIGNING_KEY="$SIGNING_KEY_PATH" ./scripts/release.sh stable 1.8.0
+PTLINUX_SIGNING_KEY="$SIGNING_KEY_PATH" ./scripts/release.sh prerelease 1.9.0-beta.1
 ```
 
-The command creates `dist/v<VERSION>/`, validates the channel/version pair,
+The command creates `.artifacts/releases/v<VERSION>/`, validates the channel/version pair,
 builds and previews release notes, runs the configured preflight, creates a
 deterministic archive, signs the manifest, and verifies the complete result. It
 changes the requested version only inside the staged package, so the source
@@ -24,11 +25,15 @@ releases after `0.9.11` return to the flat layout.
 Use `--description` for short Markdown or `--description-file` for a prepared
 Markdown document. Generated commit notes are appended by default. Run
 `./scripts/release.sh --help` for dry-run, editor, changelog-only, signing-key,
-and test options.
+output-directory, and test options. Custom release output must remain below
+`.artifacts/releases/` or an operating-system temporary directory. See the
+[artifact layout and migration guide](../docs/development/ARTIFACTS.md) for all
+generated-output locations. The private signing key has no checkout default;
+provide a mode-`0600` regular file outside the repository and artifact output.
 
 After a successful build, create a new release in Gitea with tag `v<VERSION>`.
 Leave **Pre-release** clear for `stable`; select it for `prerelease`. Use
-`dist/v<VERSION>/release-notes.md` as the description and upload exactly these
+`.artifacts/releases/v<VERSION>/release-notes.md` as the description and upload exactly these
 five files from that version directory:
 
 - `PristonTale-EU-<VERSION>.tar.gz`
@@ -43,14 +48,14 @@ signed archive URL includes its SHA-256 as a query parameter so Cloudflare and
 other CDNs cannot reuse an empty response cached before the attachment existed.
 After the Gitea release exists and each attachment has a nonzero size, publish
 the matching files generated under
-`dist/v<VERSION>/channel/` to the repository:
+`.artifacts/releases/v<VERSION>/channel/` to the repository:
 
 ```text
-dist/v<VERSION>/channel/stable.json       -> updates/stable.json
-dist/v<VERSION>/channel/stable.json.sig   -> updates/stable.json.sig
+.artifacts/releases/v<VERSION>/channel/stable.json       -> updates/stable.json
+.artifacts/releases/v<VERSION>/channel/stable.json.sig   -> updates/stable.json.sig
 
-dist/v<VERSION>/channel/prerelease.json       -> updates/prerelease.json
-dist/v<VERSION>/channel/prerelease.json.sig   -> updates/prerelease.json.sig
+.artifacts/releases/v<VERSION>/channel/prerelease.json       -> updates/prerelease.json
+.artifacts/releases/v<VERSION>/channel/prerelease.json.sig   -> updates/prerelease.json.sig
 ```
 
 Commit and push only the selected channel pair. Publishing a prerelease must not
@@ -71,8 +76,8 @@ For direct artifact tooling without release notes or manual-upload guidance:
 
 ```text
 PTLINUX_PYTHON=/path/to/python \
-  ./scripts/build-release.sh 0.9.11 stable ./dist/v0.9.11
-./scripts/verify-release.sh 0.9.11 stable ./dist/v0.9.11
+  ./scripts/build-release.sh 0.9.11 stable ./.artifacts/releases/v0.9.11
+./scripts/verify-release.sh 0.9.11 stable ./.artifacts/releases/v0.9.11
 ```
 
 The builder selects the runtime payload declared in `config.json`; it does not
@@ -101,13 +106,17 @@ must provide Git, Bash, curl, jq, Python 3.11 or newer, tar, gzip, coreutils
 uses `actions/checkout@v4` and checks that the checked-out commit is the exact
 commit referenced by the annotated tag.
 
+The tracked runner template and local setup instructions are in
+[`../infra/gitea-runner/`](../infra/gitea-runner/). Its `.env`, registration
+token, and persistent state stay outside source control.
+
 Configure these protected Actions secrets:
 
 - `RELEASE_TOKEN`: a dedicated token with only the repository release and
   repository-content write permissions needed to create releases, upload
   attachments, and update signed channel metadata.
 - `MANIFEST_SIGNING_KEY`: the private key corresponding to
-  `ptlinux/launcher-update-public.pem`.
+  `src/ptlinux/launcher-update-public.pem`.
 
 Secrets are available only to trusted tag and release-status workflows. Do not
 add the release secrets to pull-request workflows. The signing key is written under