pro_backend: fix macOS build of the C response holders

[Bilb]

Problem

The macOS jobs fail to compile src/pro_backend.cpp while Linux is green:

error: no matching constructor for initialization of 'GetProRevocationsCResponse'
  return unique_ptr<_Tp>(new _Tp(_VSTD::forward<_Args>(__args)...));
note: in instantiation of function template specialization
      'std::make_unique<GetProRevocationsCResponse, session::pro_backend::GetProRevocationsResponse>'
note: candidate constructor (the implicit copy constructor) not viable ...
note: candidate constructor (the implicit move constructor) not viable ...
note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided

Same failure for GetPaymentDetailsCResponse. Seen on the Xcode 15.4 runners, e.g. https://github.com/session-foundation/libsession-util-nodejs/actions/runs/31062340831/job/92492725217?pr=66

Cause

GetProRevocationsCResponse / GetPaymentDetailsCResponse are aggregates deriving from their C++ response type, and the *_parse functions build them straight from a parsed base response:

std::make_unique<GetProRevocationsCResponse>(parse_revocations({json, json_len}));

make_unique initializes with parentheses (new T(args...)), so initializing an aggregate that way requires P0960R3 (parenthesized aggregate initialization, C++20). GCC implements it — hence green Linux builds — but the Apple Clang on the macOS runners does not, so it looks for a constructor, finds only the implicit copy/move/default ones, and none accept a base-class argument.

It is not a bad pin or a stale submodule: the code is only ever valid on compilers that have P0960.

Fix

Give each holder an explicit base-slice constructor, so the existing call sites resolve to a real constructor on every compiler. Call sites are unchanged.

The defaulted default constructor is kept deliberately — set_c_protocol_error<Owned> default-constructs these to carry a diagnostic:

auto owned = std::make_unique<Owned>();

Declaring it = default on first declaration keeps it non-user-provided, so make_unique<Owned>() still value-initializes exactly as it did while the type was an aggregate.

Verification

• Reduced repro of the pattern: fails to compile as-is under -std=c++17 (a faithful stand-in for a compiler without P0960, and it reproduces the identical "no matching constructor" diagnostic), compiles with the fix. Checked under both GCC 15 and Clang 21, at C++17 and C++20.
• src/pro_backend.cpp syntax-checks clean with the project's real compile flags from compile_commands.json.
• clang-format reports no changes against the repo's .clang-format.

I could not build on macOS directly, so the Apple Clang leg is inferred from the reduced repro rather than observed — worth letting CI confirm.