chore(agent): bump 0.5.26 → 0.5.27 for the decoupled collector (#1228)

[lotgon]

#1228 decoupled the native collector's reported version (.module/Collector version now = the collector's own 0.6.1, not the managed 3.4.12) but did not bump the agent that embeds the collector. Per src/agent/AGENTS.md, a collector change compiled into the agent alters the shipped binary → the agent version must bump, so self-update delivers it. Bump 0.5.26 → 0.5.27.

🤖 Generated with Claude Code

[github-actions]

PR Review — #1229: bump agent 0.5.26 → 0.5.27 for the decoupled collector

Verdict: ✅ Approve. This is a correct, minimal, single-line version bump that follows the project's documented policy.

Summary of change

src/agent/CMakeLists.txt: project(HsmAgent VERSION 0.5.26 ...) → 0.5.27. One insertion, one deletion.

Correctness

• The rationale is sound and matches the directory-scoped rule in src/agent/AGENTS.md: a change compiled into the agent binary that originates in the native collector (here, chore(native): decouple collector version from managed + versioning docs/rules #1228's collector version decoupling) alters the shipped binary and must bump HsmAgent VERSION in the same PR so self-update can deliver it. This PR does exactly that.
• The bump is a proper monotonic patch increment (0.5.26 → 0.5.27), so src/update_checker.cpp's semver comparison (major → minor → patch) will see the new version as strictly greater and deployed agents will pick it up. This avoids repeating the feat(native): collector logging parity — built-in file logger + events + tests #1221 "same-version rebuild is invisible" precedent called out in AGENTS.md.
• Completeness verified: the version is defined only in CMakeLists.txt (compiled in as HSM_AGENT_VERSION). A search of src/agent/ found no other hardcoded 0.5.2x occurrence that would need to be kept in sync, so no drift is introduced.

Bugs / logic errors

None found.

Security

No security-relevant surface. No new inputs, dependencies, or code paths — only a build constant.

Code quality / maintainability

Minimal and focused. Commit and PR description clearly explain the "why" and link the originating change (#1228). Good practice.

Performance

Not applicable.

Minor notes (non-blocking)

• Nothing to change. As a general observation, tying the delivery-critical version to a single build-file constant remains a maintainability risk (easy to forget on a collector-only PR) — but that's an existing design property, already documented and guarded by AGENTS.md, not something introduced here.

🤖 Generated with Claude Code