docs: add NEAR AI Inference SDK guides

[hanakannzashi]

Summary

• Add an SDK section alongside Verification under Private Inference.
• Organize Gateway SDK guidance into E2EE, Verification, and OHTTP tabs.
• Cover response verification, TCB policy, and Node/browser/proxy behavior.
• Keep the direct-endpoint route for existing integrations, marked experimental and listed under Experimental.
• Redirect the previous verification-scoped SDK paths to their new locations.

Validation

• git diff --check origin/main...HEAD
• jq empty docs.json
• GitHub broken-links check

[PierreLeGuen]

Thanks @hanakannzashi. I ran all four examples verbatim against production with @nearai/inference-sdk@next (0.1.0-rc.3) on Node 24:

• Gateway E2EE, and Gateway E2EE + OHTTP: ok, then Verified provider_tee response.
• Direct E2EE + OHTTP: same.
• Direct E2EE: 1 of 3 runs failed in verifyResponse() with a signature 404. That's the per-instance cache limitation the page already warns about, so the page is accurate.

Approving. Two small suggestions inline: the SDK's default TCB policy (it accepts OutOfDate), and the direct-endpoint credentials sentence. Also worth doing, here or in a follow-up:

• The direct SDK page isn't linked from anywhere. Adding cloud/inference-sdk/direct to the new Experimental group in docs.json, next to Direct Completions, would fix that. I'll link it from the Experimental page once this merges.
• The env var is NEARAI_API_KEY here but NEAR_AI_CLOUD_API_KEY in the verification and E2EE guides. Pick one.
• @next is rc.3 while latest is still rc.1. Drop @next once 0.1.0 ships.

SDK-side, not docs: with a strict policy, the tcb_status_not_allowed rejection surfaces as a generic Connection error., and the real reason is only in error.cause. The direct 404 also reads "Cloud API completion signature returned HTTP 404", which is misleading for a direct endpoint.

[hanakannzashi]

Also retained NEARAI_API_KEY: it is the established convention in the integration guides. The older verification examples that use NEAR_AI_CLOUD_API_KEY can be normalized separately.