fix(swiftpm): fix two ways array build settings were mishandled

[chrfalch]

Summary:

Two bugs in addArrayStringValues, the helper that adds members to an array build setting (HEADER_SEARCH_PATHS, OTHER_LDFLAGS, FRAMEWORK_SEARCH_PATHS, LD_RUNPATH_SEARCH_PATHS). Both hit real projects; neither was visible from the existing fixture.

1. A promoted scalar was never restored. When the setting already exists as a scalar, it gets promoted to a ( … ) array — but that was recorded as a plain member-append, so deinit stripped the members and left the array shell plus its injected "$(inherited)" behind. The original scalar was never recorded, so it couldn't be put back. Stock Xcode projects hit this: the app template sets LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks"; as a target-level scalar.

Fixed by pinning the pre-injection value in .spm-injected.json and restoring it in place. Three details: the value is stored raw (a bare scalar's token runs to the ;, so it carries whitespace that must come back); it's recorded only if the merge actually changed the field (otherwise deinit would overwrite a setting we never touched); and restoration is skipped if the field is gone, so a setting deleted after add isn't resurrected.

2. A one-line array was corrupted. The append anchored on lastIndexOf('\n', tokenEnd - 1), which assumes multi-line. With no newline in the value that lands on the previous line, so members were spliced above the field, outside the array:

{
		"/new",                             ← bare entry in the dict body: invalid pbxproj
	HEADER_SEARCH_PATHS = ("/vendor", );    ← member never added
}

One spm add produced a project Xcode can't open, and deinit couldn't remove the stray line. Xcode writes multi-line arrays, but hand-edited projects and other generators (XcodeGen, Tuist) emit compact ones.

Fixed by splicing inline ahead of the ), matching the separator style already there. Reformatting to multi-line would change the user's formatting and need the old shape recorded to stay reversible. Removal gained delimiter-anchored patterns for the shapes add now produces, so the span removed is the span inserted.

Also: the dedupe parse split on every ,, so a member holding a quoted comma ("$(FOO(x)),weird") parsed as two tokens and defeated the exact-token check. Now quote-aware.

Known tradeoff: reversing a promotion rewrites the whole field, since the injected members and the seed are indistinguishable from the user's own once folded together. Members hand-added to a promoted array afterwards are lost; the removal-helper banner says so.

Changelog:

[Internal] [Fixed] - SwiftPM: spm deinit restores a promoted scalar build setting, and spm add no longer corrupts a one-line array

Test Plan:

yarn jest packages/react-native/scripts → 722 tests, all green.

Written red first. Byte-identical add → deinit round-trip for every pre-existing shape: absent, multi-line array, bare and quoted scalars (including trailing whitespace and an empty value), and the one-line forms (), ("/a"), ("/a", ), ("/a","/b"), ("/a", "/b"). Plus add → update → deinit, a user-added member surviving deinit, and an injector-level test that a project with a one-line setting stays delimiter-balanced.

The multi-line path is unchanged byte-for-byte — verified with a differential harness loading the previous implementation alongside the new one over 48 add/remove cases, plus a test pinning its exact output bytes.

[meta-codesync]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D114317839.

[cipolleschi]

A comment left by @fabriziocucci:

Two tiny things, both non-blocking and maybe I'm missing context:

1. The recording side still dedups by substring (existing.value.includes(v)) while add now dedups by exact member. I think they can't really disagree here since the values are quoted paths, so it seems harmless, just a bit inconsistent with the diff's own theme.
2. topLevelCommas is quote-aware but not paren-aware, so an unquoted member with a comma inside parens would mis-split. I don't think that happens for real pbxproj array settings since those members are quoted, so edge-only.