add Octra provider in addition to GitHub and Filesystem

[WiggidyW]

Add an Octra provider for retrieving agents, swarms, functions, and profiles, alongside the existing Github and Filesystem providers.

Motivation

Octra is an L1 with a Decentralized Storage Network (DSN) built around fully homomorphic encryption (FHE). The interesting property for ObjectiveAI: encrypted-at-rest artifacts that the API can decrypt and execute, but the end user (and anyone else) cannot read.

That gives us a path to private/proprietary agents, swarms, profiles, and prompts — protect the prompt, swarm composition, and learned weights from extraction while still allowing execution through the API. GitHub/Filesystem providers can't do this; they assume the bytes are public to anyone with the path.

Scope

Add a new Remote::Octra variant and a parallel client implementation everywhere Remote::Github / Remote::Filesystem exist today:

• objectiveai-sdk-rs/src/remote.rs — add the enum variant + RemotePath::Octra { ... }
• objectiveai-api/src/retrieval/retrieve/octra/ — new client implementing the Client<CTXEXT> trait (mirroring github/github.rs)
• objectiveai-api/src/retrieval/retrieve/router.rs — add Octra dispatch arms
• objectiveai-api/src/retrieval/list/ — decide whether listing is supported (see open questions)
• objectiveai-cli/src/remote.rs and objectiveai-cli/src/functions/inventions/remote/mod.rs — add the CLI value-enum variants
• objectiveai-rs-wasm-js / objectiveai-js — surface the new variant through the WASM bindings + TS SDK

Open design questions

These should be resolved before/during implementation, not after:

1. Listing. GitHub has repo trees; the filesystem has directories. A DSN typically returns by content hash and has no native "list everything." Options: (a) skip listing for Octra entirely, (b) require a per-owner on-chain registry, (c) defer until we have a usage pattern.
2. Versioning / resolve_latest. Current providers resolve branch -> commit SHA. Content-addressed storage is immutable by hash, with no "head" concept. Likely: Octra paths require the hash directly and resolve_latest is a no-op (or rejects when no explicit commit is provided).
3. Decryption authority. Where does the API hold the key material to decrypt? Per-owner keys vs. per-artifact keys? How does an artifact author grant the API decrypt access without granting end users decrypt access?
4. Encrypted upload tooling. Need a CLI / WASM path for users to publish an encrypted agent to Octra such that the API can decrypt it but they cannot. Likely a separate follow-up issue.
5. Cost / latency. DSN reads vs. raw GitHub fetches — need to make sure the per-request caching in Router::resolve_path and the persistent cache absorb this.

Maturity caveat

Octra mainnet alpha launched December 2025. The DSN, SDK, and HTTP surface may still be unstable; expect the integration to track upstream changes for a while. Worth scoping this as "experimental provider" until APIs settle.

Refs

• https://docs.octra.org/
• https://octra.org/litepaper.pdf