Switch mesh core module asset from hardcoded ARTIFACTORY to GITHUB release

[mikhailm-coder]

Why

Deployed OpenFrame machines get the mesh agent's JS core from a frozen snapshot baked into this repo's JAR (ToolAgentFileController + openframe-client-core/src/main/resources/meshcentral-core-module, marked TODO: remove after github artifact is implemented). Edits to CoreModule.js in the meshagent repo never reach machines. The GITHUB asset mechanism this TODO was waiting for now exists and is proven by fleet's osqueryd asset — this PR migrates the mesh core module onto it.

What

• meshcentral-agent.json: meshcentral-core-module asset flips ARTIFACTORY → GITHUB, with downloadConfigurations pointing at the same meshagent release archives that deliver the binary (targetFileName: CoreModule.js). One artifact, one tag — core/binary skew becomes impossible.
• IntegratedToolAgentInitializer: the asset's version is wired to openframe.client-versions.mesh (mirrors the osqueryd pattern), so every mesh version bump re-downloads the core on deployed machines via the standard asset-update path.

ToolAgentFileController, the JAR blob, and the client's ARTIFACTORY path are deliberately left in place — old installation messages sit on persistent NATS topics and can be replayed. Cleanup is a follow-up PR after the fleet migrates.

⚠️ Deployment ordering (load-bearing)

Do not deploy this against a mesh version whose release archives lack CoreModule.js:

• CoreModule.js ships in meshagent archives starting with the release cut from Ship CoreModule.js in both release archives meshagent#79 (expected 0.1.1). Releases ≤ 0.1.0 do not contain it.
• If openframe.client-versions.mesh points at an older release when this deploys, the asset download fails and aborts fresh mesh installs (existing machines are unaffected — hasAssetChanges treats the null→versioned transition as no change, so nothing is published until the next mesh version bump; that bump-driven rollout is the intended semantics).
• Correct order: meshagent#79 merged → release cut → MESH_CLIENT_VERSION bumped to it → this deploys.

Known accepted trade-offs

• Install/update fetches the same archive twice (binary + asset). Few MB, 429→jsDelivr fallback exists; a shared-archive cache is a possible later optimization.
• Client builds pinned via the meshcentral-agent-version feature pin only the binary (meshcentral-server tool id), not this asset — a pinned build would take the asset from the server-sent version. Follow-up candidate in tool_version_overrides.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • MeshCentral agents now consistently apply the configured version to both the agent and its core module.
  • Windows and macOS core modules now download from the correct GitHub source.
  • Existing filenames and non-executable behavior remain unchanged.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5e60a923-4f99-4346-b5bd-0fbf0ae45697

📥 Commits

Reviewing files that changed from the base of the PR and between d5dd846 and e65a1fe.

📒 Files selected for processing (2)

• openframe-management-service-core/src/main/java/com/openframe/management/initializer/IntegratedToolAgentInitializer.java
• openframe-management-service-core/src/main/resources/agent-configurations/meshcentral-agent.json

---

📝 Walkthrough

Walkthrough

MeshCentral core module downloads now use GitHub sources for Windows and macOS. MeshCentral version overrides now apply to both the agent and its core module asset.

Changes

MeshCentral core module

Layer / File(s)	Summary
Configure GitHub core module downloads openframe-management-service-core/src/main/resources/agent-configurations/meshcentral-agent.json	The core module downloads CoreModule.js from GitHub for Windows and macOS. The asset remains non-executable.
Synchronize core module versions openframe-management-service-core/src/main/java/com/openframe/management/initializer/IntegratedToolAgentInitializer.java	MeshCentral version overrides now update the top-level agent and meshcentral-core-module asset versions.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: aliaska-varieva, denys-gif

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes switching the MeshCentral core module asset from Artifactory to GitHub releases.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch hotfix/mesh-coremodule-github-asset

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kirill-567]

Why not approach we discussed before?
Mesh have native way for the core module management.

[mikhailm-coder]

Old pr, working on discussed solution atm; Closing this👌