Replace local compat shims with clean upstream Jido dependencies

[mikehostetler]

Summary

jido_code currently carries a repo-local compat/ directory to satisfy :jido_os and :jido_workflow surfaces that the app and jido_code_server expect. That made wrapper PR CI self-contained, but it now reads like a partial vendor/fork and adds ongoing maintenance overhead.

We should remove compat/ and have this repo consume clean upstream packages instead, while still keeping CI and fresh contributor clones self-contained.

Current findings

• Root mix.exs currently points :jido_os to compat/jido_os and overrides :jido_workflow with compat/jido_workflow.
• The real upstream jido_os exists in mikehostetler/jido_os and appears to expose the public modules/functions jido_code already calls.
• jido_workflow is still expected by jido_code_server through the legacy JidoWorkflow.Workflow.Loader and JidoWorkflow.Workflow.Engine APIs.
• Neither jido_os nor jido_workflow is currently available on Hex.
• jido_code is on Elixir ~> 1.18, while upstream jido_os and jido_code_server currently target ~> 1.19.
• The original compat intent was to avoid requiring a sibling checkout and to avoid CI dependence on external/private dependency resolution.

Desired outcome

Remove the local compat/ folder and replace it with an upstream dependency strategy that is clean, reproducible, and CI-friendly.

Acceptance criteria

• compat/ is removed from jido_code.
• jido_code no longer depends on sibling workspace checkouts for jido_os.
• CI and fresh contributor clones can resolve dependencies without special local workspace layout.
• Dependency sourcing for both jido_os and workflow runtime is explicit and documented.
• The coding assistance surface continues to work against upstream jido_os.
• Workflow asset registration/execution continues to work without the local compat/jido_workflow shim.
• Elixir/toolchain expectations are aligned across jido_code, jido_code_server, and upstream runtime dependencies.

Recommended approach

1. Decide the upstream sourcing model for jido_os.
   • Either consume upstream via direct Git pin as an intermediate step, or make it publish-ready and consume it as a released package.
2. Align the Elixir baseline.
   • If upstream jido_os remains on ~> 1.19, this repo likely needs to move from ~> 1.18 to ~> 1.19 before the compat layer can be dropped cleanly.
3. Remove compat/jido_os.
   • Replace the local path dep with the upstream dependency and verify compile/runtime behavior for the public Jido.Os.* surface already used here.
4. Resolve workflow runtime ownership.
   • Either switch to a direct upstream jido_workflow dependency, or migrate jido_code_server workflow handling onto native Jido.Os.Workflow.* services so jido_workflow can be eliminated entirely.
5. Remove compat/jido_workflow and keep regression coverage.
   • Preserve or expand tests around coding assistance and workflow.run.* so the repo proves the new dependency path works end to end.

Notes

I attempted to assign this to psharbon per request, but that handle is not assignable on mikehostetler/jido_code. I assigned the issue to pcharbon70 as the most likely intended assignee.