Exclude symbolic links from dependency discovery

The scheduled dependency update in the Settlers application failed before it could open its non-major update PR: run 40450092261.

Package discovery follows storage/framework/defaults, a generated directory link into the installed node_modules/@stacksjs/defaults package. It then proposes an update to storage/framework/defaults/package.json, which is not an owned repository file. The Git writer correctly refuses to create that missing update target after refreshing the branch. Its safety check must remain intact.

A public PackageScanner.scanProject() regression with a real filesystem reproduces the problem: an owned root manifest, an owned workspace manifest and an installed framework directory link produce three manifests instead of the two owned ones. Separate real-file cases reproduce linked manifest admission in adapter discovery and workspace-catalog discovery.

Source owner: Buddy package, adapter and catalog discovery. Application ignore rules are not the correction, because the link can have any name and must not become a writable update target.

Acceptance:

• Preserve the public scanner, adapter and catalog red regressions with real directory/file links and no filesystem mocks.
• Exclude symbolic-link manifests and aliased directories from discovery, including .github and workflow directory components. Avoid recursive cycles and dangling-link disruption.
• Keep real workspace, vendored/defaults, catalog and workflow manifests discoverable. Do not weaken missing-target or write-boundary checks.
• Run focused and complete tests, lint, types, documentation claims and build checks.
• Publish through the existing patch-release command, verify the released package and release gates, run installed-package checks against real Stacks/application checkouts and rerun the affected application workflow successfully.

This changes source discovery ownership. It grants no new token permissions and does not change dependency version policy or auto-merge rules.

The first release corrected the public package scanner, adapter and catalog paths, but the actual workflow rerun still failed. Its npm update path uses an independent RegistryClient filesystem walk that I missed. The write guard continued to reject the installed framework target correctly.

A new public getOutdatedPackages() regression reproduces that second path with real filesystem links, real Bun lockfile/outdated commands and a local fixture registry. It returns an update to the installed package before the correction. The corrected registry walk excludes that alias and generated directories while still returning the owned root and workspace updates. No scanner internals, fetch globals or subprocesses are mocked. The final workflow recovery check remains pending.

Released in Buddy 0.11.15. The public scanner and registry update path exclude installed-package links, and the native CLI runs version and doctor from a consumer project without executing its Bunfig preloads. The release now builds and verifies SDK/native artifacts before publication and checks that native ZIPs do not enter the npm package.

Validation: 2,454 source tests, lint, types, documentation and SDK/native build checks passed. The original npm tarball matches registry SHA-512/SHA-1 metadata. All five original native ZIPs match GitHub asset digests, checksums and the release source manifest, with every archive CRC verified. The published macOS ARM64 executable passes the maintained consumer check and runs normally in the game checkout. Actual installed SDK checks pass for both Stacks and the game.

The first reruns still selected the old transitive CLI from the application lockfile. The normal better-dx dependency chain is now locked to 0.11.15 in Stacks and the game, without adding a duplicate direct dependency. After frozen installation, their ordinary local commands report 0.11.15. The fresh application workflow completed successfully, including lockfile regeneration and creation of its dependency pull request. No ignored-target exception or write-guard change was needed.