Semantic Kernel hot reload sits inside a bare string literal and never runs

@Bionic711 is already working on this.

Since Aug 22, 2026.

**Severity: medium to high, operational. Fix available.**

`application/single_app/app.py` around lines 598 to 607 contains a call to
`initialize_semantic_kernel()` inside a bare triple-quoted string literal. Python
evaluates it as a discarded expression statement, so it never executes. There is
no syntax error and no warning.

What makes this hard to notice: fourteen call sites across
`route_backend_agents.py` and `route_backend_plugins.py` set
`builtins.kernel_reload_needed = True`, and the single consumer clears the flag
while rebuilding nothing. The flag therefore looks consumed. In global kernel
mode every settings change requires a full process restart to take effect, and
nothing tells the operator that.

**Suggested fix.** Re-enabling the call as written introduces a race, so the fix
needs guarding. A module-level lock with double-checked locking prevents
concurrent rebuilds. Clearing the flag inside the lock before the rebuild begins
means no request blocks on a rebuild and a settings change landing mid-rebuild
sets the flag again rather than being lost. A failed reload should keep the
previous kernel, because a stale kernel serves requests correctly with older
settings while a missing kernel breaks chat outright. Reload is meaningless in
per-user kernel mode, where kernels are already rebuilt per request and the
global publish path is skipped, so it should be scoped out there.

An AST sweep for this defect class across all 201 application files found only
four bare non-docstring string expression statements: this one, the deliberate
disabling of multi-agent orchestration in `semantic_kernel_loader.py`, and two
misplaced prose blocks. So the class is rare enough to fix exhaustively and then
guard with a test.

---

Found while enabling features on a fork of `v0.250.001`, verified against commit `ff8059163e09ede433003b1ed2822061c41239fe`. Line numbers are against that baseline.

We have a working fix and a functional test for this on our fork. Happy to open a PR if that is useful, or to share the patch and let you take a different approach. No expectation either way.