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).

The issue concerns the safe creation of a `.goosehints` file in shared workspaces. Research involves understanding the current file creation logic in the Desktop codebase, specifically around workspace path verification. Examine how the canonical path and device/inode checks are performed. Look for the file creation call and the surrounding race condition. The outcome is a documented threat model and a decision on whether to implement a native helper using `openat`-style operations, refuse creation on certain filesystems, or explicitly exclude the scenario.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.