fix: base Git multi-file Compose deploy env and dossier on the effective config (#1391)

* fix: resolve the root .env at deploy and render time for Git context-dir stacks

A Git multi-file source with a context dir set --project-directory to that
dir, so Docker Compose looked for .env there and missed the root .env Sencho
writes. Validation already passed the root .env with --env-file, so a stack
could validate with one effective config but deploy or render another.

Add authoredComposeEnvFileArgs, which appends --env-file <stackDir>/.env when
the applied deploy spec has a context dir and a root .env exists, and wire it
into the deploy/update, image-scan, render, and container-listing compose
invocations so they all resolve env from the same file the validator used. A
non-ENOENT access error surfaces instead of silently dropping the flag.

* fix: base multi-file Git dossier and doc-drift on the effective Compose model

The Stack Dossier and its documentation-drift check parsed only the stored root
compose file. For a multi-file Git source, services, ports, networks, or volumes
that an override file adds were invisible, so the dossier showed incomplete facts
and doc-drift could falsely warn that a documented port is unpublished when an
override actually publishes it.

Add a secret-safe GET /stacks/:name/effective-anatomy that renders the merged
effective model and extracts only structural facts (services, ports, volumes,
networks, restart), never env, label, or command values. StackAnatomyPanel
fetches it for multi-file Git stacks and feeds those facts into the dossier and
doc-drift, falling back to the root-only parse for single-file or non-git stacks
and whenever the render is unavailable.

* fix: add an inline path-injection barrier to the Git env-file resolver

CodeQL js/path-injection flagged the fs.access in authoredComposeEnvFileArgs
because the env path derives from the route-supplied stack name and the only
containment check lived in the callers, not at the sink. Resolve the stack dir
against the compose base and assert containment with startsWith inline, then
derive the .env path from the validated dir, mirroring the existing inline guards
in renderConfig and validateCompose. Valid stack names are unaffected; a name
that escapes the base now yields no --env-file.

* test: stabilize the dossier doc-drift e2e against the dossier-load race

The first assertion filled the access_urls field as soon as the Dossier panel
was visible, but the panel's GET /stacks/:name/dossier resolves by overwriting
the fields from the server (empty access_urls) and only then flips the doc-drift
gate on. When the GET landed after the fill, it clobbered the typed value and the
warning never rendered, so the test failed intermittently under CI timing. Wait
for that GET to land before typing, mirroring the spec's openStack helper.

backend/src/utils/authoredComposeArgs.ts

@@ -1,4 +1,5 @@
 import path from 'path';
+import { promises as fsPromises } from 'fs';
 import { DatabaseService } from '../services/DatabaseService';
 import { NodeRegistry } from '../services/NodeRegistry';
 import { isPathWithinBase, isValidRelativeStackPath } from './validation';
@@ -55,3 +56,47 @@ export function authoredComposeFileArgs(stackName: string, nodeId?: number): str
 
   return args;
 }
+
+/**
+ * Build the `--env-file <stackDir>/.env` flag a multi-file Git deploy needs when
+ * the applied spec sets a context dir, or `[]` otherwise.
+ *
+ * When `authoredComposeFileArgs` emits `--project-directory <contextDir>`, Docker
+ * Compose treats the context dir as the project directory and looks for `.env`
+ * there, not at the stack root where Sencho writes it. `validateCompose` passes
+ * the root `.env` explicitly with `--env-file` whenever the stack has env content,
+ * so without the same flag at deploy/render/scan time a Git source could validate
+ * with one effective config and deploy or render another. This flag makes every
+ * compose invocation resolve env from the same root `.env` the validator used.
+ *
+ * Scoped to the context-dir case on purpose: with no `--project-directory`, the
+ * project directory stays the stack dir (the compose command's cwd) and Compose
+ * auto-discovers the root `.env`, so single-file / no-context stacks need no flag
+ * and keep their existing behavior. An explicit `--env-file` to a missing file
+ * errors, so the flag is only added when a root `.env` actually exists.
+ */
+export async function authoredComposeEnvFileArgs(stackName: string, nodeId?: number): Promise<string[]> {
+  const resolvedNodeId = nodeId ?? NodeRegistry.getInstance().getDefaultNodeId();
+  const spec = DatabaseService.getInstance().getGitSource(stackName)?.applied_deploy_spec;
+  if (!spec || spec.files.length === 0 || !spec.contextDir) return [];
+
+  // Inline js/path-injection barrier at the fs sink: resolve against a known-safe
+  // base and assert containment with startsWith right here. CodeQL does not credit
+  // the wrapped isPathWithinBase helper or a check separated from the sink, matching
+  // the inline guards in renderConfig and validateCompose. `.env` is a fixed name.
+  const baseResolved = path.resolve(NodeRegistry.getInstance().getComposeDir(resolvedNodeId));
+  const stackDir = path.resolve(baseResolved, stackName);
+  if (!stackDir.startsWith(baseResolved + path.sep)) return [];
+  const envPath = path.resolve(stackDir, '.env');
+  try {
+    await fsPromises.access(envPath);
+  } catch (err) {
+    // A missing `.env` is the normal "nothing to pass" case. Any other error
+    // (e.g. EACCES on an existing but unreadable `.env`) is a real fault: surface
+    // it rather than silently dropping the flag and deploying a different effective
+    // config than the one validated.
+    if ((err as NodeJS.ErrnoException).code === 'ENOENT') return [];
+    throw err;
+  }
+  return ['--env-file', envPath];
+}