Document host-native release launchers

docs/consumers/adoption.md

@@ -12,7 +12,6 @@ From the consumer module's root, select the ReleaseKit version to adopt:
 : "${RELEASEKIT_TOOL_VERSION:?Set the released ReleaseKit version to adopt}"
 go get -tool "go.maximumdirect.net/releasekit/cmd/releasekit@${RELEASEKIT_TOOL_VERSION}"
 go mod tidy
-go tool releasekit version
 ```
 
 Select a release that implements the API, profile, and workflow you are adopting.
@@ -39,9 +38,15 @@ A launcher invoked from that module can forward commands directly:
 
 ```sh
 #!/bin/sh
+releasekit_host_os=$(go env GOHOSTOS) || exit $?
+releasekit_host_arch=$(go env GOHOSTARCH) || exit $?
+export GOOS="$releasekit_host_os" GOARCH="$releasekit_host_arch"
 exec go tool releasekit "$@"
 ```
 
+Save this launcher as `releasekit` and run `./releasekit version` from the
+selected module to verify registration. It preserves the consumer's workspace
+and toolchain settings while selecting the host for the executable.
 For a launcher callable from other directories, first change to its consumer
 module directory. Follow the [CLI contract](../cli.md) for commands and exit
 statuses, and the [configuration reference](../config.md) for the release profile.
@@ -108,6 +113,10 @@ selection, so the committed module files also govern CI delivery and retries.
 Registering the CLI as a tool is sufficient for
 consumers that use ReleaseKit only for maintainer commands.
 
+Update copied launchers and workflow templates separately when upgrading the
+module dependency. ReleaseKit tests the generic bootstrap; consumer wiring tests
+can focus on selectors and profile mapping. Profiles continue to select
+application build targets.
 Upgrade the module-selected tool and workflow together. For a tag created before
 that upgrade, retry with the workflow matching the tool recorded at that tag.
 Keep its immutable module files and tag intact. See the