[Feature]: PIM ↔ REST/HTTP PSM data mapping declared on the PSM types #389

What type of issue is this?

• Bug report
• Feature request

Description

The PIM → REST/HTTP PSM correspondence is a specification artifact (§8.1.2, Table 9), yet the
SDK ships both type families and the serializers for both while leaving the translation to
every consumer.

Request: declare the mapping on the PSM types.

The methods cannot go on the IResponse / IRequest markers, because ToPim() would have to
return object — the PIM has no common supertype (Record covers 6 types, IData 3, and
DataDifference, MergeResult, Constraint, PrimitiveConstraint have neither base nor
interface). Self-typed generic sub-interfaces keep the markers intact:

• IPimMappable<TRecord> — TRecord ToPim() and void FromPim(TRecord record)
• IResponse<TRecord> : IResponse, IPimMappable<TRecord>
• IRequest<TRecord> : IRequest, IPimMappable<TRecord>

Each PSM type names its own counterpart, e.g. Project : IResponse<PIM.DTO.Project>.
FromPim is an instance mutator because static abstract interface members are unavailable on
netstandard2.1 (CS8919). The non-generic markers are untouched, so
SerializeResponse(IResponse) and the @type dispatch keep working. One generic mapper —
Map<TPsm, TRecord>(…) where TPsm : class, IPimMappable<TRecord>, new() — then serves both
families with no registry and no reflection.

Opt-in, not universal: Error and IConstraint have no PIM counterpart, and MergeResult
maps to two PSM types depending on outcome (§7.2.3), so those keep the plain marker and a
hand-written helper. Roughly 11 of 14 response models and 10 request models fit the contract.
The members that are not name-aligned need care: Branch.head / Tag.taggedCommit →
referencedCommit, DataDifference ids → reference objects, and the Data union.

Tests: round-trip (FromPim then ToPim is identity) across every type on the contract.

Blocked by #388.

Steps to Reproduce

System Configuration

• SysML2.NET version: 0.24.1
• Environment (Operating system, version and so on): Windows 11, any
• .NET Framework version: net10.0 / netstandard2.1
• Additional information: the abstraction was compiled against netstandard2.1;net10.0 to
  confirm it works on both targets.