How do you choose between NoInfer<T>, satisfies, and const type params when designing APIs?

Question presented to candidate: "You are designing a small TypeScript library API, say a router or an i18n helper. When would you use satisfies, when a const type parameter, and when NoInfer? Walk me through how you decide."

What a strong answer should cover:

• They solve three different problems: satisfies checks a value against a type without changing its type; <const T> makes a generic infer literal, readonly types from what the caller writes; NoInfer<T> stops one argument from contributing to inference
• Who uses each: satisfies is written by the caller at a declaration (TypeScript 4.9); const type parameters (5.0) and NoInfer (5.4) are written by the library author in the signature
• const T only affects literals written inside the call; a pre-declared variable is already widened, which is where the caller's as const satisfies X comes in
• NoInfer is needed only where a second argument would add candidates (literal unions); keyof T and object arguments are often already checked
• They compose: const on the source-of-truth parameter, NoInfer on the dependent one, satisfies on the caller's config objects
• Version floor: using them in a published signature requires consumers on a TypeScript version that understands them

Clarifying questions expected:

• Am I the library author or the caller, and can I change the function signature?
• Which TypeScript version must consumers of the library support?

Code / implementation expected: Yes — one API signature that uses const and NoInfer, plus a caller-side satisfies.