Make TextBundleWrapper init nullable and fail on non-UTF-8 text

[jkmassel]

Follows the pattern from #25964. Highest real-world risk in the audit: reachable via a user-supplied file through the Share Extension, with a guaranteed crash. It grew from that TextBundleWrapper crash fix into surfacing any share-extraction failure to the user, instead of swallowing it.

Summary

• TextBundleWrapper's initWithContentsOfURL:options:error: (and initWithFileWrapper:error:) are declared _Nonnull under NS_ASSUME_NONNULL_BEGIN, but return nil on any read failure — an unreadable URL, a missing info.json, or a missing text file.
• The text property is declared nonnull but is assigned from [[NSString alloc] initWithData:… encoding:NSUTF8StringEncoding], which is nil on non-UTF-8 bytes — yet readFromFilewrapper: still returned YES, so a structurally valid bundle could initialize with text == nil.
• ShareExtractor imported the initializer as non-optional and non-throwing, then dereferenced bundleWrapper and bundleWrapper.text. A nil NSString bridged to non-optional String traps.
• Separately, extraction failures were swallowed: ShareExtractor collected whatever loaded and silently dropped the rest, so a failed share opened a blank editor with no signal.

Fix — TextBundleWrapper

• Mark both initializers nullable. An error:-parameter initializer with a nullable return bridges to a Swift throwing initializer.
• After decoding text, fail the read (return NO with TextBundleErrorInvalidFormat) when the result is nil, so text stays honestly nonnull.
• Annotate fileWrapperForAssetFilename: nullable to match its own doc comment.

Fix — surface extraction failures

• TypeBasedExtensionContentExtractor.convert(payload:) is now throws; the error from the throwing TextBundleWrapper init propagates up handleTextBundle → handleTextPack → processLocalFile → URLExtractor.convert to the NSItemProvider.loadItem boundary, where it's logged.
• extract(...) returns (items, failures) per provider — accumulated under an NSLock, since loadItem calls back concurrently — and loadShare returns a ShareLoadOutcome: the assembled share, the skipped attachments, and whether anything usable was extracted.
• The share and draft extensions act on the outcome (shared helpers on ShareExtensionAbstractViewController):
  • Nothing extracted and something errored → NSExtensionContext.cancelRequest(withError:), via the existing dismissal path, behind an alert.
  • Some attachments failed, others loaded → a non-blocking notice; keep editing.
  • Merely empty (e.g. an empty text selection — no content, no error) → open the editor as before. Empty is not a failure.

Test plan

• WordPress app and its embedded Share Extension build (generic iOS Simulator).
• Sharing a valid .textbundle/.textpack imports as before.
• Sharing a malformed bundle (missing text file / non-UTF-8 text) no longer crashes — the extension cancels with an alert.
• Sharing good content alongside a malformed attachment loads the good content and shows the skipped notice.
• Sharing an empty selection opens the editor with no error alert.

Adds Share Extension strings under shareExtension.contentError.* and shareExtension.partialError.*.

Part of the Objective-C non-null nullability audit; see #25964.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	34143
	Version	PR #25968
	Bundle ID	org.wordpress.alpha
	Commit	19e22d7
	Installation URL	5v1r4en5vjg10

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	34143
	Version	PR #25968
	Bundle ID	com.jetpack.alpha
	Commit	19e22d7
	Installation URL	7hrd37n50c240

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.

[dangermattic]

	2 Warnings
⚠️	Modules/Package.swift was changed without updating its corresponding Package.resolved. If the change includes adding, removing, or editing a dependency please resolve the Swift packages as appropriate to your project setup (e.g. in Xcode or by running swift package resolve). If the change to the Package.swift did not modify dependencies, ignoring this warning should be safe, but we recommend double checking and running the package resolution just in case. .
⚠️	Package.swift was changed without updating its corresponding Package.resolved. If the change includes adding, removing, or editing a dependency please resolve the Swift packages as appropriate to your project setup (e.g. in Xcode or by running swift package resolve). If the change to the Package.swift did not modify dependencies, ignoring this warning should be safe, but we recommend double checking and running the package resolution just in case. .

Generated by 🚫 Danger