Introduce PrefixSecurityMode string literal union type

[colincasey]

Part of #581.

Motivation

RFC 6265bis-22 introduces cookie prefixes (__Secure-, __Host-). tough-cookie supports three enforcement modes for these prefixes: silent, strict, and unsafe-disabled. Currently the prefixSecurity option is typed as string at most call sites, despite PrefixSecurityEnum already defining the valid values as constants.

Current usage

// Constants define valid values
const PrefixSecurityEnum = {
  SILENT: 'silent',
  STRICT: 'strict',
  DISABLED: 'unsafe-disabled',
} as const;

// But the option is typed as plain string
interface CreateCookieJarOptions {
  prefixSecurity?: string | undefined  // accepts any string
}

class CookieJar {
  prefixSecurity: string  // any string
}

// Internal normalization handles invalid values
function getNormalizedPrefixSecurity(prefixSecurity: string): PrefixSecurityValue {
  // falls back to 'silent' for unrecognized values
}

Type design

Like SameSiteLevel, this is a string literal union since the valid values are a small, fixed set:

export type PrefixSecurityMode = 'silent' | 'strict' | 'unsafe-disabled';

This type already exists in practice — PrefixSecurityEnum defines these exact values.

API strategy

Public API change (narrowing — justified)

Property	Current type	New type	Breaking?
CreateCookieJarOptions.prefixSecurity	string | undefined	PrefixSecurityMode | undefined	Technically yes — but unrecognized values silently fall back to 'silent', so passing anything else was already a no-op bug
CookieJar.prefixSecurity	string	PrefixSecurityMode	Same rationale

Rationale for public change

• The three values are already exhaustively defined by PrefixSecurityEnum
• getNormalizedPrefixSecurity() silently corrects invalid values — the type change surfaces these hidden bugs at compile time
• No runtime behavior change