[JJenkx]

What

Retain the supplied LibContext pointer in each Matches model at root offset +0x08. MatchesFactoryCreate currently puts it only in the output IntrusivePtr, leaving the model field zero. Native model construction writes both; the native deleter also reads the model field. This changes the shared constructor initialization, without changing allocation policy, exports or the existing context validation.

Source: static inspection of the bundled libSceNpCppWebApi.prx from PPSA21564 (RemovedPlayerFactory::create at 0x140790, context store at 0x1407e2) and PPSA05347 (create 0xfb6c0, constructor chain ending at 0xfb370, store at 0xfb382, deleter 0xfb7a0). Provider hashes and bounded observations are attached. This was not measured on a console. Custom allocator callbacks remain unimplemented and are documented in debt.

This is independent of #16262 (occupied-output ownership) and #16128 (remaining factories). Both merge cleanly with this change; neither implements model-context initialization. There is no functional dependency. No title unblock or performance gain is claimed.

Tested

Windows qualification from our independent worker: exact cad789a4cc merged cleanly onto newer main 87448b3c91 as c7a0a64ee2, Windows 11 Enterprise22621/WinLibs GCC15.2 UCRT Release. All14 NP CPU tests pass three runs, zero skips. The same Matches fixture against that newer main code fails the +8 context assertion. Exact-head Windows result and main control. Linux qualification below uses its separate pinned base.

Linux x86_64, Ryzen 7950X, GCC 16.2.1 Release C++20. Head cad789a4cc921577acb5d39e1673fe7d93a55cfa on main c36ab99c74cde292a75c75c6ab2dc989a047bb7d.

• Scoped actual NP production CMake plus 13 selected CPU cases: 13/13 pass, zero skips. Model context is checked for all 12 implemented factory types across 13 successful creation calls.
• The same final Matches fixture, loaded against the frozen main c36 NP library, fails at the missing-context assertion; restoring the candidate provider passes. Fixture/library hashes remain unchanged.
• Private combination with fix(npcpp): release occupied Matches factory outputs #16262 at 1fa538392374dc3ffc7bb91aa2b7a8feee53808e and feat(np): implement remaining Matches2V1 factories and AppLauncher launch error #16128 at dd45a14c82b96e82e403a37147bf9740d6ae2ebd, combined head 23dca4cfd221c5041cf7413d8faef603e32e9665: 13/13 selected NP CPU cases pass, zero skips. AppLauncher from feat(np): implement remaining Matches2V1 factories and AppLauncher launch error #16128 was not built/tested.
• Public header audit, conventions and whitespace pass. The final 1,888-open-PR overlap scan reports no functional overlaps. It fails closed on stale fix(relinker): match AppContent utility import to provider #13486/docs(debt): separate entries with blank lines and drop derived export totals #14212; manual comparison confirms their shared factory helper is unchanged, and their debt additions do not implement this field.

The seven dependency provider libraries are frozen from previously qualified main ef0d852; the NP module is freshly built from the pinned current sources. The Linux run is not a full SDK, console or title test; Windows evidence is separate above. No GPU test is needed for this CPU layout change.

Source patch, CMake scope, logs/JUnit, negative control, exact pins and provenance, SHA-256 5da51c4d2c09d672079eee6361ee0e771373810a5fea50fcafab0f13d6857fed. No proprietary files are attached.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: n/a (CPU layout change)
• AI-assisted: yes (Codex)

[JJenkx]

Windows check of exact head cad789a4cc, merged onto current main 87448b3c91 (c7a0a64ee2, clean merge). Main has moved past the c36ab99c74 named in the PR, so the merge base differs.

Setup: Windows 11 Enterprise 22621, WinLibs GCC 15.2 UCRT, Release, with its own source and build trees. The hosted Windows check does not run these tests on pull requests.

	Result
This PR merged	all 14 guest_np_cpp_web_api* tests pass in 3 of 3 runs, none skipped
Control: main 87448b3c91 code with only this PR's GuestNpCppWebApiMatches.cpp	guest_np_cpp_web_api_matches fails: requirement failed at core/libs/tests/GuestNpCppWebApiMatches.cpp:256

Line 256 is Require(Read<const void*>(created.object, 0x08) == &context), the LibContext at +8 check. So the fixture fails on main's code and passes with this change, on Windows too.

AI-assisted: yes.