docs: establish the constellation Git baseline

Condense the working handoff into implemented state, activation evidence and open choices. Record both repositories, flag superseded SharePoint setup instructions and undocumented input/support changes, and align the design with completed workbench organization.

Keep the generated nvim.log locally but ignore it. Both flakes evaluated successfully and whitespace checks passed. No implementation behavior changes, tests, builds, activation or remote writes.

docs/constellation.md

@@ -42,11 +42,13 @@ use a flake to declare its tools without Nix owning the surrounding workspace.
 - Yookr workbench is an investigation environment, not a product repository.
   Its placement and versioning can be considered separately.
 - Accepted direction: workbench supplies the environment at the company-workspace
-  root. Its maintained tooling and reusable HTTP/SQL files still need a clear home;
+  root. Its reusable requests live in `workbench/http/` and queries in
+  `workbench/databases/`, grouped by service/database;
   the company root need not itself be a Git repository.
 - Expose native capabilities and useful context rather than a menu of predetermined
-  investigations. The user rejects the current `k8s-inventory` and custom `mail`
-  direction. API/database organization and broader system access remain exploratory.
+  investigations. The custom inventory and mail helpers are archived; native
+  Garden/kubectl/K9s own the documented Kubernetes workflow. Mail retrieval and
+  broader system access remain exploratory.
 - Accepted interaction direction: find HTTP requests by service; start database
   exploration from a named connection. Keep targets visible and use the existing
   execution vocabulary. Working queries should survive restart without automatically