Add getConstraint() and getDefault() getters to TypeParameter

[Copilot]

The TypeParameter API object exposed no direct way to read a type parameter's constraint or default. Reading a constraint required Checker.getConstraintOfTypeParameter(type), and no getter existed for the default at all — inconsistent with SubstitutionType, which already has getConstraint().

// before: only via the checker, no default getter
const constraint = await checker.getConstraintOfTypeParameter(tp);

// now
const constraint = await tp.getConstraint(); // Type | undefined
const def = await tp.getDefault();           // Type | undefined

Changes

• Client interface (async/types.ts): add getConstraint() and getDefault() to TypeParameter, both returning Type | undefined.
• Client impl (async/api.ts):
  • TypeObject.getConstraint() dispatches on TypeFlags.TypeParameter — type parameters resolve through the checker endpoint getConstraintOfTypeParameter, while substitution types keep the existing preloaded-handle path.
  • getDefault() calls the new getDefaultFromTypeParameter endpoint.
  • Add fetchCheckerType registry helper for checker-level endpoints keyed by type that resolve to a single optional type (mirrors fetchBaseTypes).
  • Sync API/tests regenerated from the async source.
• Server (internal/api): register getDefaultFromTypeParameter in proto.go and add handleGetDefaultFromTypeParameter in session.go, delegating to the already-exported checker.GetDefaultFromTypeParameter and returning null when absent.
• Tests: async/sync coverage for a constrained + defaulted type parameter and one with neither (both getters return undefined).

Notes for review

getConstraint() is kept as a single method that branches on type flags rather than duplicated, preserving SubstitutionType's preloaded-handle behavior while giving type parameters checker-backed resolution.