fix(spm): scaffold app-package paths relative to the libs/<Name> symlink

A scaffolded community-library Package.swift referenced the app's codegen and
xcframeworks packages with paths computed relative to the dep's real
node_modules dir (relFromDep). But the autolinker references each library
through a symlink at build/generated/autolinking/libs/<SwiftName>, and on a
fresh SwiftPM resolve the manifest's relative `.package(path:)` entries are
interpreted against that SYMLINK location (SwiftPM does not canonicalize the
symlink first). So `../../ios/build/generated/ios` resolved to the doubled,
nonexistent `…/autolinking/ios/build/generated/ios` → "Could not resolve package
dependencies". This bit any fresh resolve (only a stale Package.resolved hid it).

Compute the paths relative to the symlink dir instead: codegen → `../../../ios`,
xcframeworks → `../../../../xcframeworks`. SCAFFOLDER_VERSION bumped 7→8 so
existing manifests auto-regenerate on the next scaffold/sync.

Verified E2E on /tmp/SpmE2E and ~/spikes/Spm1 (remote mode): re-scaffold via the
v8 tooling, fresh resolve (clean DerivedData + Package.resolved) BUILD SUCCEEDED.
Known follow-up: the sibling-dep path (emitScaffoldedPackageSwift
`../${siblingName}`) is still dep.root-relative and uses the npm name rather than
`libs/<swiftSibling>` — same class, only hit when a scaffolded lib depends on
another RN lib (reanimated→worklets).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: chrfalch

packages/react-native/scripts/spm/__tests__/scaffold-package-swift-test.js

@@ -459,6 +459,30 @@ end
     expect(content).toContain(SCAFFOLDER_MARKER);
   });
 
+  it('computes app paths relative to the libs/<SwiftName> symlink, not dep.root (fresh-resolve correctness)', () => {
+    makePodspec();
+    const result = scaffoldPackageSwiftForDep(makeDep(), makeCtx());
+    expect(result.status).toBe('written');
+    const content = fs.readFileSync(
+      path.join(depRoot, 'Package.swift'),
+      'utf8',
+    );
+    // swiftName = ReactNativeFoo; the autolinker references the dep via
+    // build/generated/autolinking/libs/ReactNativeFoo. SwiftPM resolves the
+    // manifest's relative paths against THAT location, so:
+    //   build/generated/ios  -> ../../../ios
+    //   build/xcframeworks    -> ../../../../xcframeworks
+    expect(content).toContain(
+      '.package(name: "React-GeneratedCode", path: "../../../ios")',
+    );
+    expect(content).toContain(
+      '.package(name: "ReactNative", path: "../../../../xcframeworks")',
+    );
+    // The old dep.root-relative form (doubled to …/autolinking/ios/build/...
+    // through the symlink) must NOT be emitted.
+    expect(content).not.toContain('../../ios/build/generated/ios');
+  });
+
   it('reports previouslyExisted=false for first-time scaffolds (so the CLI can prompt)', () => {
     makePodspec();
     const result = scaffoldPackageSwiftForDep(makeDep(), makeCtx());

packages/react-native/scripts/spm/scaffold-package-swift.js

@@ -80,7 +80,10 @@ const {log} = makeLogger('scaffold-package-swift');
 // the scaffolder regenerates regardless of --force (the bump implies the
 // existing file is broken under current tooling). A file with the marker
 // but no version line is treated as v1.
-const SCAFFOLDER_VERSION = 7;
+// v8: relative app paths (codegen / xcframeworks) are now computed from the
+// autolinker's libs/<SwiftName> symlink location instead of the real dep.root,
+// fixing a doubled-path resolution failure on fresh SwiftPM resolves.
+const SCAFFOLDER_VERSION = 8;
 const SCAFFOLDER_VERSION_LINE_RE = /^\/\/ AUTO-SCAFFOLDED-VERSION: (\d+)$/m;
 
 const AUTOGEN_MARKER =
@@ -635,18 +638,35 @@ function scaffoldPackageSwiftForDep(
   }
 
   const spec = translatePodspecToSpmTarget(model, dep);
-  // Relative paths from the dep's package dir (where Package.swift lands)
-  // into the app — posix separators, as SPM expects.
-  const relFromDep = (...segments /*: Array<string> */) =>
+  // Relative paths into the app, embedded in the scaffolded Package.swift.
+  //
+  // The manifest is written to <dep.root>/Package.swift, but the autolinker
+  // references the dep through a symlink at
+  // <appRoot>/build/generated/autolinking/libs/<SwiftName>. On a fresh resolve
+  // SwiftPM interprets a manifest's relative `.package(path:)` entries against
+  // that SYMLINK location (it does not canonicalize the symlink first), so the
+  // paths must be relative to the symlink dir — NOT the real dep.root.
+  // Computing from dep.root produced a doubled path
+  // (…/autolinking/ios/build/generated/ios) → opaque "package manifest cannot
+  // be accessed" resolution failure. posix separators, as SPM expects.
+  const symlinkDir = path.join(
+    ctx.appRoot,
+    'build',
+    'generated',
+    'autolinking',
+    'libs',
+    spec.swiftName,
+  );
+  const relFromManifest = (...segments /*: Array<string> */) =>
     path
-      .relative(dep.root, path.join(ctx.appRoot, ...segments))
+      .relative(symlinkDir, path.join(ctx.appRoot, ...segments))
       .split(path.sep)
       .join('/');
   const content = emitScaffoldedPackageSwift(spec, {
     cacheSlotLabel: ctx.cacheSlotLabel,
     remote: remotePackageConfig(ctx.appRoot),
-    codegenPackageDir: relFromDep('build', 'generated', 'ios'),
-    localXcfwPackageDir: relFromDep('build', 'xcframeworks'),
+    codegenPackageDir: relFromManifest('build', 'generated', 'ios'),
+    localXcfwPackageDir: relFromManifest('build', 'xcframeworks'),
   });
 
   // Distinguish "first-time scaffold" (no file at all) from "regenerate"