Refine Briosa documentation architecture, catalog, and API references

[davidalucas]

Summary

• reorganize the site into version-independent product documentation, an API chooser, separate gRPC/.NET/Python/JavaScript reference sections, and a dedicated MP Command Catalog
• rewrite the introduction, startup, first-request, compatibility, execution-outcome, and single-tenant guidance around the product experience users need
• preserve the exact-target SpatialAnalyzer group hierarchy while introducing canonical cross-version command entries that avoid duplicate search results across SA releases
• document Get Working Directory end to end across the MP catalog, gRPC API, and all three first-party client contracts, with bidirectional links between command semantics and callable APIs
• add representative Open SA File and Save As... catalog entries without implying a Briosa release commitment
• improve responsive navigation, code presentation, the mobile menu, GitHub navigation, footer repository links, and consistent title capitalization
• retain redirects for the previous documentation and operation routes

Why

Issue #18 began as a refinement of the content-first MP catalog layout. During maintainer review, the work exposed related information-architecture and product-guidance problems across the site. This branch resolves those issues together so the catalog, API references, and user documentation form one coherent navigation model before the full MP inventory is documented.

User impact

Readers can now understand why Briosa exists, start from the recommended first-party client experience, choose the correct API reference, browse SpatialAnalyzer commands through their native group hierarchy, and move directly between an MP command's canonical semantics and each available Briosa API.

The catalog distinguishes supported APIs from commands that are still being evaluated. The client reference pages describe the reviewed first-release contracts and explicitly note that pre-release bootstrap implementations may differ.

Validation

• Node.js 24 npm run check
• TypeScript typecheck and optimized Docusaurus production build
• rendered route and bidirectional-link checks across product, gRPC, client, and catalog sections
• legacy-route redirect checks
• desktop and narrow-width visual review of navigation, catalog pages, code tabs, header, and footer
• exact-target hierarchy reconciliation retained from the original issue implementation

Closes #18