feat(swap): add model profiles and FreeToken readiness integration

[dbourdea]

FreeToken swap integration with two explicit modes: native authenticated profile lifecycle controls with launch/readiness rollback and durable accounting, plus automatic inference routing through pinned unmodified llama-swap using the new /ready endpoint. Do not double-supervise one engine. Includes safe catalog validation, process lifecycle protections, uncached readiness, recovery invalidation by newer operator actions, private-cache configuration, and maintenance qualification harnesses. Validation: the combined swap and AMD repair tree passed 114 Linux daemon/privacy/benchmark/reproducibility tests plus 21 Qwen model tests. The latest Windows daemon suite passed 78 with 4 platform skips. Real GMKtek EVO-X2 tests passed Qwen3.6-to-Qwen3.8-to-Qwen3.6 ordinary/SSE routing, same-model and conflicting-model concurrency, usage reporting, TTL unloading, and client cancellation. Same-instance terminal abort was observed 0.254 seconds after disconnect, followed by successful A-to-B-to-A streaming. Native daemon recovery also passed after an intentionally invalid GGUF fixture caused the real loader to fail: HTTP 503 was retained, the prior Qwen3.6 model recovered readiness and generated the expected streamed answer. Its sealed accounting receipt was complete; the failed loader crash receipt was explicitly degraded. Both approved live phases restored the protected llama.cpp service and verified generation; final process/listener checks were clean. Model fixes are in PR #2. Provenance, architecture, security constraints, evidence, and completion audit are in docs/freetoken-swap*.md. Limits: manual native catalog is not automatic inference routing; direct llama-swap mode does not use daemon durable accounting or native rollback. Long-context quality, broad model coverage, and long-duration endurance are not claimed. Semaphore-cleanup warnings remain a follow-up despite final worker cleanup. Raw deployment logs stay private; public hardware name is GMKtek EVO-X2. Draft for maintainer review, not a production activation or merge request. All publication is confined to FreeToken; no llama.cpp or llama-swap PR or source modification is included.

[dbourdea]

GMKtek EVO-X2 isolated AMD smoke result

The profile was tested in a separate clone at PR commit 14f344e on GMKtek EVO-X2: AMD Radeon 8060S gfx1151, ROCm 7.15.26333, Python 3.12.13. No pre-existing FreeToken daemon or serve was running. The test used temporary state only and loopback ports 1940 and 1941.

Observed:

• the daemon started, listed the Gemma profile, spawned the profile serve, and exposed loading through /engine/health
• Gemma 4 selected Triton attention and offload MoE, with 56.00 GiB free before loading
• the engine remained in FreeToken health state loading beyond the configured 300-second readiness window, so no completion was sent and this is not a successful workload qualification
• ft daemon stop produced a sealed, non-degraded zero-request accounting receipt; POST /shutdown closed both temporary ports and no temporary daemon or serve remained

An earlier Qwen3.6 attempt was rejected correctly because the tested mainline revision only recognizes gemma4 GGUF. The first Gemma attempt exposed a missing native pinned-memory extension in the fresh clone; the retry used an already-built compatible artifact only inside the temporary clone. No production checkout or existing service was modified.

Follow-up code adds deterministic timeout coverage. Current targeted validation: 38 passed, 2 skipped.

[dbourdea]

Follow-up at commit c980106: added ft daemon shutdown [--force], which invokes the daemon's existing serialized /shutdown transaction. This closes the cleanup gap discovered in the GMKtek EVO-X2 isolated smoke test. Targeted validation is now 39 passed, 2 skipped, including client shutdown routing and readiness-timeout coverage.

[dbourdea]

Second GMKtek EVO-X2 isolated smoke result

A separate disposable clone based on amd-rocm-gfx1151 received the freetoken-swap commits and used the existing GMKtek EVO-X2 native pinned-memory extension only within that clone. The daemon and profile control plane ran on loopback ports 1950 and 1951. No existing checkout or service was modified.

Results:

• Qwen3.6-27B-Q4_K_M reached the profile engine-error result with a scheduler weight materialization mismatch: expected tensor size 4200, got 2880.
• Qwen3.8-27B-Q4_K_M reached the profile engine-error result because the installed Transformers 5.16.1 GGUF integration has no qwen35 tokenizer converter. The backend reported freetoken-detokenizer-0 exited during load.
• Each failure was returned by start-profile as readiness.reason=engine-error with the engine health document, then the daemon was shut down through the new CLI command. Both temporary ports were closed and no temporary process remained.

These are current AMD model/runtime compatibility blockers, not freetoken-swap lifecycle failures. A successful representative completion requires a known-good FreeToken-compatible model plus tokenizer/runtime baseline on GMKtek EVO-X2.

[dbourdea]

Added daemon launch-failure rollback under the existing lifecycle lock. If replacement spawning fails before an owned child exists, the previous exact model/port/arguments are relaunched. HTTP 503 reports recovery launch status separately from readiness and retains accounting evidence. Failed recovery is explicit; accounting failures still preserve the original engine. Full daemon suite: 57 passed, 2 skipped. This is CPU failure-injection coverage, not a new GPU maintenance test. Readiness-failure rollback and direct-supervisor rollback remain incomplete.

[dbourdea]

Added --cancellation to the isolated qualification harness. It disconnects an active SSE stream after first content, requires same-instance terminal idle without normal-completion increment, and then verifies A-to-B-to-A streaming recovery. Negative gates reject backend restart, normal completion, premature stream termination, and abort timeout. Includes an actual localhost HTTP disconnect test. Full daemon/qualification suite: 78 passed, 2 skipped. Real FreeToken GPU cancellation is not yet qualified; the next maintenance window is awaiting operator approval. No production interruption occurred in this iteration.

[dbourdea]

Real Linux CPU lifecycle validation now passes on GMKtek EVO-X2: 2 tests cover ordinary SIGTERM cleanup and SIGTERM-resistant children requiring SIGKILL. The tests use actual child process groups and loopback HTTP servers, verify previous-engine readiness recovery, exact restored arguments/pidfile, durable accounting receipts, worker cleanup, expected exit signals, and port closure. The production llama.cpp service remained active and its health returned ok afterward. This is stronger OS lifecycle evidence, not GPU model-failure or live inference-cancellation qualification. No additional maintenance window was used.

[dbourdea]

Combined-source audit: swap 64dcc68 and model-repair de23ad6 merge cleanly to tree c3c0ae54a09857b98bba83cfc75b91264e6eeb43. The isolated combined tree passed 114 Linux daemon/privacy/benchmark/reproducibility tests plus 21 Qwen model tests on GMKtek EVO-X2. No production interruption or GPU model load was needed. Both PRs remain drafts; hosted status-check lists are empty, so these are independently executed results. docs/freetoken-swap-completion-audit.md maps the full goal to evidence and identifies live GPU cancellation and native real-model failure recovery as remaining gates pending maintenance approval.

[dbourdea]

A new native-parity goal is active. Initial source-backed matrix added at docs/freetoken-swap-parity-matrix.md. It compares pinned llama-swap commit 41ec321 point by point, marks native, integrated-only, missing, and inapplicable capabilities, and makes unified FreeToken-owned automatic routing the architecture gate. This begins a new scope of work; current integration is not represented as standalone llama-swap parity.