fork: join HTTP server thread on llama_engine() shutdown (hydra_vortex #360 review)

[ddvnguyen]

Closes #16
Closes #17

Follows up on #15 (which added /v1/chat/completions to
llama-engine; that PR is already merged into hydra-fork at 8f3dc58 and
bumped in ddvnguyen/hydra_vortex#360). The review on ggml-org#360 surfaced two
findings, both in tools/llama-engine/llama-engine.cpp.

Finding 1 (P1) — std::terminate() on shutdown

After ctx_server.start_loop() returns (unblocked by the signal handler
on SIGTERM/SIGINT — e.g. a hydra-head restart), the HTTP server thread is
still blocked in pimpl->srv->listen_after_bind() (server-http.cpp:385).
server_http_context::thread is a std::thread with a defaulted
destructor (server-http.h:68), so destroying the still-joinable thread at
scope exit calls std::terminate() → SIGABRT. The hydra-head
auto-restart logic masks it, but the process never exits cleanly and the
crash-loop alerting may fire.

Live-confirmed on the #15 production build: podman
logs of hydra-system_head-rtx_1 showed
terminate called without an active exception after the deploy's auto-
restart, with a backtrace through ~server_http_context →
llama_engine → __libc_start_main.

Fix

Mirrors tools/server/server.cpp:283-285, 369-372 exactly:

ctx_server.start_loop();
if (params.port > 0) {
    ctx_http.stop();
    if (ctx_http.thread.joinable()) {
        ctx_http.thread.join();
    }
}
ctx_server.terminate();
llama_backend_free();

The if (params.port > 0) guard mirrors server.cpp's pattern of only
running HTTP teardown when the HTTP server was actually started.

Finding 2 (P2) — lifetime-ordering comment was factually inverted

The comment added in #15 at llama-engine.cpp:354-361 claimed the chosen
routes-before-ctx_http declaration order "Mirrors the lifetime
layout in tools/server/server.cpp" and that "reverse declaration order
would leave dangling captures". Both claims are wrong:

• server.cpp does the opposite (ctx_http at L122, routes at L133).
• ex_wrapper returns a std::function that captures routes.post_*
  by value; destroying it never dereferences routes, so both orders
  are safe. The real teardown hazard was the unjoined HTTP thread (Finding
  1), not lambda captures.

The declaration order is fine — the comment now accurately describes
what it does and cross-references #16.

Verification

• clang -fsyntax-only clean
• cmake --build build_sm120 --target llama-engine (RTX, sm_120)
• Live bug reproduction: podman logs of the production engine
  showed the exact std::terminate() from this issue
• cmake --build build_sm60 --target llama-engine (P100, sm_60)
• Live fix verification: SIGTERM against the new binary
  → process exits 0, no SIGABRT, no zombie. Deferred to the
  hydra-vortex deploy step (production engine uses 14.4 GB GPU and
  the container's /llama/bin is read-only, so the new binary
  can only land via an image rebuild — the right place to verify
  end-to-end).

Cross-repo

• Hydra parent PR (open): fix: [Llama-Engine-P0] register /v1/chat/completions + join HTTP thread on shutdown (closes #356) hydra_vortex#360 — submodule pointer
  will be force-pushed to this PR's merge SHA after it lands
• Original PR (merged): fork: llama-engine /v1/chat/completions (hydra_vortex #356) #15
• Review posted on: fix: [Llama-Engine-P0] register /v1/chat/completions + join HTTP thread on shutdown (closes #356) hydra_vortex#360 (the parent PR)