⚠️ Potential issue | 🟠 Major

These helpers do not remove the busybox init cost yet.

Both functions are stubs, and the comments explicitly say the real registration still happens through package-import side effects. In the consolidated binary, those init() paths still run before dispatch, so non-central components will continue paying the compliance/GraphQL initialization cost this PR is trying to isolate.

Verify each finding against the current code and only fix it if needed.

In `@central/app/init.go` around lines 47 - 65, The stub initCompliance and
initGraphQL still rely on package init() side-effects so the unwanted
initialization cost remains; replace the implicit side-effect imports by calling
explicit registration functions during central startup: in initCompliance call
the concrete registration routine (e.g.,
compliance/checks/remote.MustRegisterChecks or equivalent exported
RegisterAllChecks function) instead of relying on package init(), and in
initGraphQL invoke the GraphQL loader registration entrypoint (the
package-exported function that performs RegisterTypeFactory for all loaders)
rather than importing packages for side effects; remove any blank (_) imports
that trigger init() and ensure initCompliance and initGraphQL perform the
explicit calls in the central init path.

issue (bug_risk): Central mode now runs premain and initialization twice and default mode misses app-level init

In the central case, both app.Run() and CentralRun() are called. Since app.Run() already invokes memlimit.SetMemoryLimit() and premain.StartMain(), and CentralRun() also calls premain.StartMain(), premain now runs twice. Meanwhile, the default branch calls only CentralRun() and skips app.Run(), so app-level init (metrics registration, compliance/GraphQL setup) is missed.

Please refactor so there is a single, consistent initialization path—for example, by having all memlimit/premain logic live in app.Run() and always invoking it before CentralRun(), or by making CentralRun() the single entry point that performs initialization and is called from app.Run().

issue (bug_risk): Avoid calling premain.StartMain (and other early-init) twice for the central binary

For the "central" case, both app.Run() and CentralRun() are now called. Since app.Run() calls premain.StartMain() and CentralRun() still invokes it via the old centralRun logic, premain runs twice, risking double-initialization, extra goroutines, or panics. Centralize premain.StartMain() (and other early-init like memlimit/metrics) in a single path—e.g., only in app.Run() and remove it from CentralRun(), or ensure only one of these is called from main().

⚠️ Potential issue | 🟡 Minor

Default-to-central path skips the new central init flow.

The "central" branch runs app.Run() before CentralRun(), but the fallback only calls CentralRun(). If this binary is invoked under any unexpected name, it will start central without the new metric/compliance/GraphQL initialization even though the log says it is defaulting to central mode.

 	default:
 		// Default to central if called with unknown name
 		log.Warnf("Unknown binary name %q, defaulting to central mode", binaryName)
+		app.Run()
 		CentralRun()
 	}

Verify each finding against the current code and only fix it if needed.

In `@central/main.go` around lines 1111 - 1113, The fallback path that handles
unknown binary names logs defaulting to central but skips the new initialization
flow by calling CentralRun() directly; update the fallback to invoke app.Run()
(the same initialization performed in the "central" branch) before calling
CentralRun() so metric/compliance/GraphQL startup is performed; locate the
log.Warnf("Unknown binary name %q, defaulting to central mode", binaryName)
branch and insert or call app.Run() prior to CentralRun().