Docs: qualify deinit's byte-identical promise for a promoted setting

`spm add` promotes an array build setting that is already present as a scalar
(`HEADER_SEARCH_PATHS`, `OTHER_LDFLAGS`, `FRAMEWORK_SEARCH_PATHS`,
`LD_RUNPATH_SEARCH_PATHS`), and reversing that promotion rewrites the whole
field, because the injected members and the user's own are indistinguishable
once folded together. Members hand-added to such an array afterwards are lost
on `deinit`, and on `update`, which reverts to the recorded baseline before
re-injecting. The docs claimed the pre-`add` restore was byte-identical with
no qualification.

## Summary:

- Follow a stock Xcode app target being an instance of this (the template
  writes `LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks";`
  as a target-level scalar), so the caveat reads as concrete rather than
  theoretical, and note that an existing array keeps the shape it was written
  in — including the one-line form hand edits and other generators emit.
- The `.spm-injected.json` row of "What to commit" described the marker as a
  record of injected edits only; it also pins the pre-injection value of a
  build setting `add` rewrote.

Docs only; no behavior change.

## Changelog:

[Internal] - SwiftPM: document that `deinit` cannot preserve members added by
hand to a promoted array build setting

## Test Plan:

Prose review of `packages/react-native/scripts/spm/__doc__/spm-scripts.md`.
Every claim traced to this PR's code: the recorded marker key
(`promotedArrayScalars` on `BuildSettingChange`), the settings merged as arrays
(`INJECTED_ARRAY_SETTINGS` + `frameworkArrayBuildSettings`), the whole-field
rewrite in `removeRecordedBuildSettings`, and `update` re-applying from
`removeRecordedBuildSettings(original, prevMarker…)`.

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

Author: chrfalch

packages/react-native/scripts/spm/__doc__/spm-scripts.md

@@ -161,7 +161,7 @@ package graph, or require a second build.
 | Path | Commit? | Why |
 |------|---------|-----|
 | `MyApp.xcodeproj/` | Yes | Your project, with SwiftPM injected in place. Holds your signing, capabilities, Build Phases — `add` only adds SwiftPM refs/settings, additively. |
-| `MyApp.xcodeproj/.spm-injected.json` | Yes | Marker recording every edit `add` made, so `deinit` can surgically reverse it and re-runs stay idempotent. |
+| `MyApp.xcodeproj/.spm-injected.json` | Yes | Marker recording every edit `add` made — plus the pre-injection value of any build setting it rewrote — so `deinit` can surgically reverse it and re-runs stay idempotent. |
 | `build/generated/` | No | Codegen/autolinking output; regenerated |
 | `build/xcframeworks/` | No | Symlinks to the machine-local artifact cache |
 | `Package.resolved` | No | SwiftPM resolution file; machine-specific |
@@ -173,7 +173,22 @@ stays untouched, and a re-run is a no-op. The injected refs point at three
 stable sub-package paths under `build/`; adding or removing community deps
 changes the sub-package contents (gitignored) and never re-injects. `deinit`
 removes exactly what was injected (using the marker), leaving the project
-byte-identical to its pre-`add` state.
+byte-identical to its pre-`add` state — with one exception, described next.
+
+**Build settings that already exist** are edited in place. The four array
+settings `add` merges into — `HEADER_SEARCH_PATHS`, `OTHER_LDFLAGS`,
+`FRAMEWORK_SEARCH_PATHS`, `LD_RUNPATH_SEARCH_PATHS` — keep the shape they were
+written in: Xcode's multi-line form as well as the compact one-line form hand
+edits and other generators (XcodeGen, Tuist) emit. One that exists as a plain
+*scalar* is promoted to a `( … )` array — the shape an Xcode-authored target can
+carry, e.g. a
+`LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks";` written
+as a scalar rather than a list. `add` records the pre-injection value in the
+marker and
+`deinit` restores it by rewriting the whole field — once folded together, the
+injected members and your own are indistinguishable — so **members you add to
+a promoted array by hand afterwards are lost**. That applies to `update` too,
+which reverts to the recorded baseline before re-injecting.
 
 Because everything under `build/` is gitignored, a clean checkout has no
 resolvable Swift packages until they are regenerated — see the next section.