Define atomic .goosehints creation for shared workspaces

**What problem would this solve?**
Desktop can create a missing `.goosehints` file inside the active workspace. Its current confinement checks identify the workspace through a canonical path and device/inode, while the final create still opens `workspace/.goosehints` by pathname. On a shared or network workspace where another actor can rename or replace parent-directory entries concurrently, path checks before and after the open cannot prove that the created file remained under the same parent. We need to decide whether such mutable shared workspaces are supported for this write path.

**What would a good outcome look like?**
Document the supported workspace/filesystem threat model for `.goosehints` creation. If concurrently mutable parent namespaces are supported, create the file relative to a verified directory handle and verify the opened object without another pathname traversal. If they are not supported, fail safely when Desktop cannot provide that guarantee and give the user a clear alternative for creating the file. Preserve the existing no-overwrite behavior.

The verification plan should include a deterministic parent-swap harness at the exact create boundary, an ordinary local workspace, a missing and existing `.goosehints`, symlink final components, and the chosen behavior on supported network/shared filesystems.

**Possible approaches**
- Add a small native helper that performs directory-handle-relative exclusive creation (`openat`-style) and validates the resulting descriptor.
- Refuse to create a missing file on filesystems where stable parent ownership cannot be guaranteed, while continuing to edit an already verified file if safe.
- Explicitly exclude hostile/multi-writer parent namespaces from the supported model and surface that limitation in Desktop.

A further pathname recheck alone does not close the race because it does not bind the opened file descriptor to the verified parent.

**Additional context**
This needs a product/platform decision because portable Node APIs do not expose the same directory-handle-relative primitive on every supported platform.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

L’issue concerne la création sûre d’un fichier `.goosehints` dans des espaces de travail partagés. La recherche consiste à comprendre la logique actuelle de création de fichiers dans la codebase Desktop, plus particulièrement autour de la vérification du chemin de l’espace de travail. Examinez comment sont effectuées les vérifications du chemin canonique et du périphérique/inode. Recherchez l’appel de création du fichier et la race condition qui l’entoure. Le résultat doit être un modèle de menace documenté et une décision quant à l’implémentation d’un helper natif utilisant des opérations de type `openat`, au refus de la création sur certains systèmes de fichiers ou à l’exclusion explicite du scénario.

Rédigé par le modèle d'indexation à partir du texte de l'issue.