docs(ios): fix Swift network-privacy regex leaving leading & in place

[fishmanalex]

Summary

• docs/sdk/ios/privacy/network.mdx: the Objective-C sample's redaction regex is access_token=[0-9a-z\-]*; the Swift sample's is &access_token=[0-9a-z\-]* — an extra leading & that requires a preceding query parameter to match.
• If access_token is the first parameter in the URL (e.g. ?access_token=SECRET), the Swift version silently leaves it in the recorded network event.
• This is sample code for a privacy/PII-redaction feature, so the bug directly undermines what the page is teaching.

Changes

• Dropped the leading & from the Swift regex so it matches the Objective-C sample's (correct) behavior.

Test plan

• npx cspell on the changed file — 0 issues

🤖 Generated with Claude Code

https://claude.ai/code/session_01QnXDhVitCVmMNafPRvKUat

[krassx]

Confirmed, and it's a real leak rather than a cosmetic mismatch. In network.mdx the Objective-C sample (line 59) uses access_token=… while Swift (line 81) had &access_token=…, so with access_token as the first query parameter (?access_token=SECRET) the Swift filter never matched and the token stayed in the recorded event. Aligning to the Objective-C pattern is the right call.

I pushed one follow-up commit (a57a06c) for a second bug in the same block:

let range = NSMakeRange(0 , (event.url!.count))
if (event.url != nil) {

The force-unwrap is on the line above the nil guard, so the guard never protected anything — a nil URL crashes the delegate. Rewrote as if let url = event.url, which covers both uses.

While there I also switched the range to url.utf16.count. NSRange indexes UTF-16 code units (which is what the Objective-C sample's -length returns); String.count counts grapheme clusters, so a URL with non-ASCII characters produced a short range that could skip matches. Shout if you'd rather I split that into its own PR — it's a one-token change on a line I was already rewriting.

cspell clean (288 files, 0 issues). LGTM.

🤖 Generated with Claude Code

[krassx]

Validated against source (see review comment above). Approving.