Remove deprecated commands and flags (#1132)

Update MCP server descriptions (#1090)
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>

bump toolhive container image (#1077)
Co-authored-by: taskbot <taskbot@users.noreply.github.com>

Implement the new User Agent sent to the update service (#1072)
Signed-off-by: lujunsan <luisjuncaldev@gmail.com>

Allow setting environment for the proxy server through the operator (#…
…983)

Add options, exposed through operator CRD, to use a CA bundle and aut…
…hentication when fetching JWKs (#978)

Don't override non-nil PermissionsProfile (#1034)

Add support for private OCI registries (#990)
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>

Fix bug where the external network is killed during run/restart (#1000)
When ToolHive starts or restarts a workload, it checks to see if a container with the same name exists. If the configuration has changed, it needs to remove the container and recreate it. This happens in a method named handleExistingContainer.
Previously, the code used the RemoveWorkload method to clean up the old container. However, when the logic to create a separate external Docker network was added, the RemoveWorkload method was extended to remove the external network if no workloads were left. If no other workloads are running during a start or restart and the run/restart involves a workload with the same name as an exited container in Docker - a situation arises where ToolHive checks to see if the external network exists, then checks to see if there is an existing container, and ends up deleting the container and the external network after checking to ensure it exists. When the MCP server starts, it goes into an error state because it has been configured to use a network which no longer exists.
It is not straightforward to move the external network check due to the sequence of operations needed to support the ingress/egress proxies (even for workloads where network isolation is disabled). Instead, I refactored the code to split the container deletion logic from RemoveWorkload into a private method, and I call that method directly in the handleExistingContainer method.

Don't attempt to remove proxy containers when network isolation is off (
#994)
This extends the work started in #967 by explicitly setting the network isolation label to false when a new workload is created with network isolation disabled.
Workloads created before this change will not have the label, and in order to ensure that it is cleaned up properly - we treat all of those legacy workloads as having network isolation enabled. To minimize the impact of this, we log the proxy container not found errors at debug level.