fix: build standalone — five things the monorepo was quietly providing

The extraction typechecked from day one and had never been built. It took five
attempts, each failing further along, and every cause was the same shape: something the
shared node_modules or the monorepo's layout supplied without anyone declaring it.

1. The config plugin had the monorepo's geometry written into it —
   ../../../packages/officer-net/ios/libs, correct from apps/<name>/ios and meaningless
   from a repo root. It reported a path belonging to neither repo. Now derived from the
   plugin's own location with path.relative, so it is right wherever the module sits.

2. That fix appeared to do nothing, because officer-net was a  dependency and bun
   COPIES those. Prebuild ran a week-old copy while the source was edited — a clean edit
   and a stale build, the same shadow-copy trap that cost a night in the monorepo.
   Making it a workspace turns node_modules/officer-net into a symlink.

3. @babel/plugin-transform-react-jsx was never declared by anything. It was hoisted into
   the monorepo by some other package, so babel-preset-expo with jsxImportSource found
   it by luck.

4. Same for react-native-reanimated and react-native-worklets: nativewind depends on
   react-native-css-interop, which lists reanimated as a PEER, whose babel plugin
   requires react-native-worklets/plugin. Three levels of nobody-declared-it.

5. And the self-inflicted one. Adding  for (2) silently flipped bun to its
   isolated linker — only direct dependencies at top level, everything else symlinked
   into node_modules/.bun, which Metro cannot resolve. It surfaced as 'Unable to resolve
   module react-native-css-interop/jsx-runtime', naming a package that was installed and
   in the lockfile and simply not where the resolver looks. bunfig.toml now pins both
   properties that are needed at once: workspaces for the symlink, hoisted for the
   layout.

Result: OffScale.app, 82 MB, with OffTailTunnel.appex at 20 MB carrying 129 Tailcore
symbols — the Go core is in the extension, which is the half that matters.

Not yet run on a device. It builds; that is a different claim.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

modules/officer-net/plugin/withNetworkExtensionTarget.js

@@ -110,12 +110,26 @@ function withNeTarget(config, props) {
     proj.addBuildPhase([], 'PBXResourcesBuildPhase', 'Resources', target.uuid);
     proj.addBuildPhase([], 'PBXFrameworksBuildPhase', 'Frameworks', target.uuid);
 
-    // Link the vendored gomobile Tailscale core (TailCore.xcframework) into the NE. The `xcode` lib has
-    // no .xcframework extension mapping, so we MUST force lastKnownFileType='wrapper.xcframework' (else it
-    // types it 'unknown' and Xcode never resolves the per-slice module → "no such module 'TailCore'").
-    // Path is relative to SOURCE_ROOT (the ios/ project dir) and includes a dirname so the search path
-    // is registered. Located in the package's libs/ (../../../ from apps/*/ios up to packages/).
-    proj.addFramework('../../../packages/officer-net/ios/libs/TailCore.xcframework', {
+    /*
+     Link the vendored gomobile Tailscale core (TailCore.xcframework) into the NE.
+
+     The `xcode` lib has no .xcframework extension mapping, so lastKnownFileType MUST be forced to
+     'wrapper.xcframework' — left as 'unknown', Xcode never resolves the per-slice module and the build
+     fails with "no such module 'TailCore'".
+
+     The path is DERIVED, not written down. It used to read `../../../packages/officer-net/ios/libs`,
+     which encodes one repository's shape — correct from `apps/<name>/ios` in the monorepo, and wrong
+     everywhere else. Moving this module into a repo of its own produced exactly that: the Go core built
+     cleanly to the right place, then xcodebuild looked for it three levels up from a directory that no
+     longer had three levels, and reported a path belonging to neither repo.
+
+     Computing it from this file's own location cannot drift: wherever the module sits relative to the
+     generated ios/ directory, `path.relative` says so.
+    */
+    const libsDir = path.join(__dirname, '..', 'ios', 'libs');
+    const iosDir = cfg.modRequest.platformProjectRoot;
+    const relLibs = path.relative(iosDir, libsDir);
+    proj.addFramework(path.join(relLibs, 'TailCore.xcframework'), {
       target: target.uuid,
       customFramework: true,
       lastKnownFileType: 'wrapper.xcframework',
@@ -126,8 +140,8 @@ function withNeTarget(config, props) {
     });
 
     const devTeam = mainAppDevTeam(proj);
-    // Framework search path → the package's libs dir (from ios/: up to the monorepo, into packages).
-    const fwSearch = '"$(PROJECT_DIR)/../../../packages/officer-net/ios/libs"';
+    // Same derivation for the search path — the two must agree, and hardcoding either is how they stop.
+    const fwSearch = `"$(PROJECT_DIR)/${relLibs}"`;
 
     const configs = proj.pbxXCBuildConfigurationSection();
     for (const key in configs) {