[API] Align the public reference and developer guide

[lrnv]

Scope

Rewrite the public API reference and developer guide so that they describe the same capability-based contract as the implementation.

Known inconsistencies to resolve include conflicting statements about whether density, conditioning, subsetting, and fitting are mandatory; inaccurate descriptions of conditional return values; and promises that generic generator primitives automatically provide operations that may not exist for singular models.

Public documentation

• list supported operations by capability rather than implying that every copula supports everything;
• document arguments, return types/shapes, boundary behavior, errors, and relevant mathematical preconditions;
• distinguish guaranteed fallbacks from optimized family-specific methods;
• give discoverable links between related operations such as conditioning and Rosenblatt transforms.

Developer documentation

• specify the minimum implementation for a new copula family;
• explain which methods are optional specializations and which enable additional capabilities;
• document constructor conventions and stable extension points;
• clearly mark internal hooks that are not part of the compatibility promise;
• include small examples for regular, singular, conditionable, and fittable families where useful.

Acceptance criteria

• public and developer pages contain no contradictory requirement tables or prose;
• every exported operation is documented once in its authoritative location;
• docs match actual dispatch and return behavior;
• executable examples cover the principal contracts where practical;
• documentation build has no new warnings or unresolved references.