docs: document plugin properties migrated from env vars

Per-plugin management docs now describe the properties introduced by the env-var-to-property migration in PR #8498, and stale prose and command-output examples that still referenced the old `DOKKU_*` names have been refreshed. The deprecated env vars table moves out of `environment-variables.md` and into the 0.38.0 migration guide, where it functions as a one-time pointer for upgrading users rather than ongoing reference material.

docs/deployment/builders/builder-management.md

@@ -82,6 +82,28 @@ The default value may be set by passing an empty value for the option.
 dokku builder:set --global build-dir
 ```
 
+#### Skipping container and image cleanup
+
+After a successful deploy, Dokku removes old containers and images that are no longer referenced by the app. On hosts where image rebuilds are expensive or where operators want to retain prior images for manual rollback, this cleanup can be disabled per-app or globally via the `skip-cleanup` property:
+
+```shell
+dokku builder:set node-js-app skip-cleanup true
+```
+
+The property can also be set globally:
+
+```shell
+dokku builder:set --global skip-cleanup true
+```
+
+The default behavior (cleanup enabled) may be restored by passing an empty value:
+
+```shell
+dokku builder:set node-js-app skip-cleanup
+```
+
+For backwards compatibility with bootstrap-time configuration, the `DOKKU_SKIP_CLEANUP` environment variable in `/etc/environment` or `~dokku/.dokkurc/*` is still honored when the `skip-cleanup` property is unset. The property is the canonical interface and takes precedence when set.
+
 ### Displaying builder reports for an app
 
 You can get a report about the app's builder status using the `builder:report` command:

docs/deployment/builders/dockerfiles.md

@@ -185,7 +185,7 @@ You would adjust the cache directory for whatever application cache you have, e.
 
 ### Customizing the run command
 
-By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base Node.js image, with the following `ENTRYPOINT`:
+By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker's ability to override the `CMD` or pass parameters to your `ENTRYPOINT` by setting the `dockerfile-start-cmd` property on the `ps` plugin. Let's say for example you are deploying a base Node.js image, with the following `ENTRYPOINT`:
 
 ```Dockerfile
 ENTRYPOINT ["node"]
@@ -194,10 +194,14 @@ ENTRYPOINT ["node"]
 You can do:
 
 ```shell
-dokku config:set node-js-app DOKKU_DOCKERFILE_START_CMD="--harmony server.js"
+dokku ps:set node-js-app dockerfile-start-cmd "--harmony server.js"
 ```
 
-To tell Docker what to run.
+To tell Docker what to run. Pass an empty value to clear the override:
+
+```shell
+dokku ps:set node-js-app dockerfile-start-cmd
+```
 
 ### Procfiles and multiple processes