[API] Stabilize the public contract before 1.0

[lrnv]

Objective

Define and stabilize the public API of Copulas.jl before 1.0, while keeping family-specific implementation hooks free to evolve internally.

The package already combines the Distributions.jl interface with copula-specific operations such as condition, subsetdims, Rosenblatt transforms, dependence measures, and fitting. The immediate problem is not necessarily missing operation names, but the absence of one explicit contract describing which operations are universal, which depend on a model capability, what fallback is guaranteed, and what package authors must implement.

Principles

• Stabilize public semantics, not accidental internal hooks.
• Do not require mathematically undefined operations (for example a density for a singular copula).
• Distinguish universal operations from capability-dependent operations.
• A public operation may be guaranteed through a generic fallback without requiring every family to specialize it.
• Treat changes to exported names, signatures, return shapes, errors, and constructor behavior as compatibility-sensitive.
• Prefer characterization and contract tests before changing implementations.
• Keep this effort focused: no speculative new API and no unrelated numerical refactoring.

Expected contract categories

The audit should determine the final classification, but at minimum consider:

• core distribution behavior: dimension, parameters, support, cdf, sampling;
• density behavior: pdf/logpdf only when the copula admits a density;
• structural operations: constructors and subsetdims;
• conditional operations: condition, Rosenblatt and inverse Rosenblatt transforms;
• estimation: supported fit methods and their discoverability;
• dependence summaries and other convenience operations;
• internal extension hooks used to provide the public behavior.

Definition of done

• the effective API has been inventoried and classified;
• every public operation has a documented semantic contract and capability requirements;
• the public and developer documentation agree with the implementation;
• representative contract tests cover universal, continuous, singular, conditionable, invertible, and fittable models;
• unsupported operations fail consistently and informatively;
• compatibility and deprecation rules up to 1.0 are documented;
• remaining intentional gaps are tracked explicitly rather than implied by tests or implementation details.

The native sub-issues track independently reviewable stages. This issue coordinates the API-stabilization effort and is itself part of #422.