Apply pre-commit linting fixes

Fix trailing whitespace and end-of-file issues across codebase.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

docs/fetching-containers.md

@@ -1,9 +1,9 @@
 # Fetching pre-built container images
-When Stack Orchestrator deploys a stack containing a suite of one or more containers it expects images for those containers to be on the local machine with a tag of the form `<image-name>:local` Images for these containers can be built from source (and optionally base container images from public registries) with the `build-containers` subcommand. 
+When Stack Orchestrator deploys a stack containing a suite of one or more containers it expects images for those containers to be on the local machine with a tag of the form `<image-name>:local` Images for these containers can be built from source (and optionally base container images from public registries) with the `build-containers` subcommand.
 
 However, the task of building a large number of containers from source may consume considerable time and machine resources. This is where the `fetch-containers` subcommand steps in. It is designed to work exactly like `build-containers` but instead the images, pre-built, are fetched from an image registry then re-tagged for deployment. It can be used in place of `build-containers` for any stack provided the necessary containers, built for the local machine architecture (e.g. arm64 or x86-64) have already been published in an image registry.
 ## Usage
 To use `fetch-containers`, provide an image registry path, a username and token/password with read access to the registry, and optionally specify `--force-local-overwrite`. If this argument is not specified, if there is already a locally built or previously fetched image for a stack container on the machine, it will not be overwritten and a warning issued.
 ```
 $ laconic-so --stack mobymask-v3-demo fetch-containers --image-registry git.vdb.to/cerc-io --registry-username <registry-user> --registry-token <registry-token> --force-local-overwrite
-```
+```

docs/gitea-with-laconicd-fixturenet.md

@@ -7,7 +7,7 @@ Deploy a local Gitea server, publish NPM packages to it, then use those packages
 ```bash
 laconic-so --stack build-support build-containers
 laconic-so --stack package-registry setup-repositories
-laconic-so --stack package-registry build-containers 
+laconic-so --stack package-registry build-containers
 laconic-so --stack package-registry deploy up
 ```
 

docs/k8s-deployment-enhancements.md

@@ -24,4 +24,3 @@ node-tolerations:
     value: typeb
 ```
 This example denotes that the stack's pods will tolerate a taint: `nodetype=typeb`
-

docs/release-process.md

@@ -26,4 +26,3 @@ $ ./scripts/tag_new_release.sh 1 0 17
 $ ./scripts/build_shiv_package.sh
 $ ./scripts/publish_shiv_package_github.sh 1 0 17
 ```
-

docs/spec.md

@@ -4,9 +4,9 @@ Note: this page is out of date (but still useful) - it will no longer be useful
 
 ## Implementation
 
-The orchestrator's operation is driven by files shown below. 
+The orchestrator's operation is driven by files shown below.
 
-- `repository-list.txt` contains the list of git repositories; 
+- `repository-list.txt` contains the list of git repositories;
 - `container-image-list.txt` contains the list of container image names
 - `pod-list.txt` specifies the set of compose components (corresponding to individual docker-compose-xxx.yml files which may in turn specify more than one container).
 - `container-build/` contains the files required to build each container image

docs/webapp.md

@@ -7,7 +7,7 @@ compilation and static page generation are separated in the `build-webapp` and `
 
 This offers much more flexibilty than standard Next.js build methods, since any environment variables accessed
 via `process.env`, whether for pages or for API, will have values drawn from their runtime deployment environment,
-not their build environment. 
+not their build environment.
 
 ## Building