fix(stack): keep Vector and Functions configs visible to fresh containers - #6945

…ners

A freshly started container can fail to see a config file a host just
replaced via temp-dir-then-rename, because some Docker file-sharing
engines (confirmed with OrbStack) cache the replaced path's previous,
now-deleted inode. Vector api/pipeline config and the Functions edge
runtime bootstrap both rewrote a fixed, bind-mounted path on every
start, so a reopened stack could intermittently log
"Config file not found" for Vector or fail to bind-mount the Functions
bootstrap.

Make both recipes content-addressed instead: each write lands at a
path derived from a digest of its content (still via temp-dir-then-
rename for atomicity). The container mounts a static directory
(Vector configRoot, the Functions bootstrap root); only the generation
name inside it, computed in args, varies. A fresh container therefore
only ever reads a name that has never been deleted before. Unchanged
content resolves to the same name and is skipped. Stale generations
are pruned once any previous container is confirmed stopped (after
args, never in prepare, which can still run while a restart's old
container is live).

Every other service recipe that bind-mounts a file was checked
(Database, Storage, Studio, Imgproxy, and the lazy-service mounts);
only Vector and the Functions bootstrap write a stack-owned file onto
a path they also bind-mount, so only those two needed this fix.

…g launches

Overlapping writers for identical content could each stage separately
and race their publish step: Vector rename replaced an already-live
file, and the Functions bootstrap rename onto an already-published,
non-empty generation failed outright. Vector now publishes with a hard
link and treats an existing link as success; the Functions bootstrap
treats a failed rename as success once the existing destination is a
complete generation. Both remove only their own stage afterward.

Pruning no longer removes staging entries (.vector-write-*,
.generation-*.tmp) that an in-flight writer may still own; only
completed, published generations are eligible, and only once a
previous container is confirmed stopped. Abandoned stages are still
removed in full by removeData/cleanupAll on destroy.

Functions args() now always publishes the bootstrap itself instead of
falling back to the caller's functions directory when nothing had been
published yet, so the recipe never silently serves a degraded main
service. The locate-only read path is gone since nothing else needed
it. The Windows-path unit test now supplies a fake bootstrap owner
instead of exercising a real one, since a real owner would join the
Win32 stack root with real fs calls and write a garbled path on a
POSIX test host.

Vector removeData now also deletes the fixed-name files earlier
releases wrote (vector-api.yaml, vector.yaml, vector.rendered.yaml),
except one that resolves to the caller's own configured pipeline; the
rendered file can carry an API token. The Functions bootstrap already
removed its entire root on cleanup, so its own legacy loose-file
layout needed no separate handling.

Error operations (prepare vs. launch) are now threaded into Vector's
write/prune helpers instead of being fixed at definition time, and
Vector and the Functions bootstrap share one content-digest helper.