Please address the comments from this code review:

## Overall Comments
- Importing the new app packages into central causes their init functions (e.g., memlimit.SetMemoryLimit in admission-control, kubernetes sensor, and compliance) to run even when the central mode is selected; consider moving these side-effectful calls from init() into the respective Run() functions so central's behavior and limits are not unintentionally altered.
- The BusyBox-style dispatcher in central defaults to running Main() for any unexpected binary name; consider logging a warning or handling unknown names explicitly so misconfigured symlinks or typos don't silently fall back to central.
- In the Dockerfiles you create multiple symlinks for the same logical tools (e.g., admission-control, kubernetes-sensor, config-controller both under /stackrox/bin and directly under /stackrox); it would be helpful to either minimize duplication or add a brief comment clarifying which paths are required for backward compatibility versus new usage.

## Individual Comments

### Comment 1
<location path="central/main.go" line_range="288-295" />
<code_context>
 	log.Info("Central terminated")
 }

-func main() {
+// Main is the exported entry point for the central binary.
+func Main() {
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider logging when an unknown binary name falls back to running Central

An unexpected `argv[0]` currently falls back to `Main()` with no signal to operators. In BusyBox-style deployments this can hide misconfigurations (e.g., typos in container `command`/`entrypoint`) and start Central when another component was intended. Please add a warning or info log in the `default:` case that includes the resolved `binaryName` to surface these issues while keeping the fallback behavior.

Suggested implementation:

```golang
	default:
		log.Infof("Unknown binary name %q, falling back to Central", binaryName)
		Main()

```

I only see part of `central/main.go`, so you may need to adapt the SEARCH block to your exact switch statement. The intent is to modify the `default:` branch of the dispatcher `switch` (the one that currently just calls `Main()`) to first emit a log line including the resolved `binaryName`, then call `Main()` as before. Ensure that `binaryName` is in scope in that `default:` branch and that `log.Infof` (or a similar info-level logging method) exists on your logger; if your logger uses a different method name or severity (e.g., `Warnf`), adjust the call accordingly.
</issue_to_address>

### Comment 2
<location path="image/rhel/konflux.Dockerfile" line_range="81-90" />
<code_context>
 RUN GOARCH=$(uname -m) ; \
     case $GOARCH in x86_64) GOARCH=amd64 ;; aarch64) GOARCH=arm64 ;; esac ; \
-    ln -s /assets/downloads/cli/roxctl-linux-$GOARCH /stackrox/roxctl ; \
+    mkdir -p /stackrox/bin && \
+    ln -s /stackrox/central /stackrox/bin/migrator && \
+    ln -s /stackrox/central /stackrox/bin/compliance && \
+    ln -s /stackrox/central /stackrox/bin/kubernetes-sensor && \
+    ln -s /stackrox/central /stackrox/bin/sensor-upgrader && \
+    ln -s /stackrox/central /stackrox/bin/admission-control && \
+    ln -s /stackrox/central /stackrox/bin/roxagent && \
+    ln -s /stackrox/central /stackrox/config-controller && \
+    ln -s /stackrox/central /stackrox/admission-control && \
+    ln -s /stackrox/central /stackrox/kubernetes-sensor && \
+    ln -s /assets/downloads/cli/roxctl-linux-$GOARCH /stackrox/roxctl && \
     ln -s /assets/downloads/cli/roxctl-linux-$GOARCH /assets/downloads/cli/roxctl-linux
</code_context>
<issue_to_address>
**suggestion:** Symlink layout is a bit inconsistent and may be confusing for consumers

The image now exposes some components in both `/stackrox/bin/<component>` and as top-level symlinks (e.g., `/stackrox/config-controller`, `/stackrox/admission-control`, `/stackrox/kubernetes-sensor`), while others like `migrator` and `compliance` only exist under `/stackrox/bin`. Please either standardize on a single convention or ensure every component entrypoint is available in both places to avoid path-dependent behavior in scripts or manifests.
</issue_to_address>