Docs: Add "Supported Languages" reference page

[Mossaka]

Summary

The docs site currently documents network ecosystem identifiers across two pages (reference/network and guides/network-configuration), but neither provides a user-friendly answer to the question: "Which programming languages can I use with agentic workflows?"

Users configuring their first workflow for a Go, Java, or Rust project have to piece together which ecosystem identifier to use, what domains it covers, and whether their language's toolchain is available in the sandbox. A dedicated reference page would make this immediately clear.

Proposal

Add a "Supported Languages & Ecosystems" page under Reference that covers the most popular languages:

Language	Ecosystem Identifier	Package Manager
Python	python	pip, conda
JavaScript / TypeScript	node	npm, yarn, pnpm
Java	java	Maven, Gradle
C / C++	defaults	System toolchain (gcc, cmake)
Go	go	Go modules
Rust	rust	Cargo
C# / .NET	dotnet	NuGet
Ruby	ruby	Bundler, RubyGems
PHP	php	Composer
Swift	swift	SwiftPM (Linux only)
Kotlin	kotlin + java	Gradle
Dart	dart	pub

The page should include:

• Overview table mapping language → ecosystem identifier → package manager
• Configuration examples (single language, JVM family, multi-language)
• Infrastructure ecosystems (defaults, github, containers) that pair with any language
• Platform note — sandbox runs Ubuntu/Linux; Swift projects requiring Apple frameworks (UIKit/AppKit) are not supported
• Link to full ecosystem list in reference/network for less common languages (Elixir, Haskell, Julia, Perl, OCaml, etc.)

Implementation

1. Create docs/src/content/docs/reference/supported-languages.md
2. Add sidebar entry in astro.config.mjs (Reference section, near "Network Access")
3. Add cross-link from reference/network.md ecosystem identifiers table
4. Add a brief pointer from guides/network-configuration.md to the new page

Why

• Reduces friction for new users who want to know "does this support my language?"
• Consolidates scattered ecosystem information into one discoverable page
• Keeps the network reference focused on configuration syntax rather than language support