docs: document Aleph VM orchestrator endpoints

[cpascariello]

Summary

• add the new docs/devhub/api/aleph-vm-orchestrator.md reference covering supervisor control, status, and confidential endpoints
• expose the orchestrator API in the DevHub sidebar (docs/.vitepress/config.mts)
• cross-link the compute resources overview (docs/devhub/compute-resources/index.md) to the orchestrator reference for automation guidance

[foxpatch-aleph]

The new orchestrator API reference is well-structured and covers the right breadth of endpoints. However, there is one broken internal link and a few gaps that will cause reader confusion: the {ref} path parameter is never defined, and the sidebar introduces an inconsistent path prefix compared to the existing REST API entry.

docs/devhub/api/aleph-vm-orchestrator.md (line 87): Broken internal link. The link target /devhub/api/rest does not exist. The existing REST API page is registered in the sidebar at /devhub/api-reference/rest, so this should be:

- [REST API documentation](/devhub/api-reference/rest)

docs/devhub/api/aleph-vm-orchestrator.md (line 29): The {ref} path parameter used throughout the machine lifecycle, log streaming, and confidential computing sections is never defined. Readers need to know what this value is (e.g. the VM item hash / message hash). Add a brief explanation near the first use, for example:

{ref} is the item hash of the VM's deployment message on the Aleph network.

docs/.vitepress/config.mts (line 344): The new entry uses path /devhub/api/aleph-vm-orchestrator while the existing REST API entry uses /devhub/api-reference/rest — two different path prefixes under the same "API Reference" section. Consider either moving the new file to docs/devhub/api-reference/aleph-vm-orchestrator.md (and updating the link) to keep all API reference docs under a consistent URL prefix, or accept the inconsistency and note it here for future cleanup.

docs/devhub/api/aleph-vm-orchestrator.md (line 72): /about/executions/details and /about/executions/records almost certainly require a query parameter (e.g. ?item_hash=...) to identify the target execution. Documenting them without any parameters will leave readers unable to use these endpoints successfully. Verify the actual query parameters against the orchestrator source and add them.

docs/devhub/api/aleph-vm-orchestrator.md (line 54): Minor consistency nit: the Status, About, and Debug endpoint tables omit the Auth column entirely, making it unclear whether these endpoints are genuinely public. A note such as "No authentication required" or an explicit Auth column with "None" would make access requirements unambiguous at a glance.