Secret storage parsing plan

[pomponchik]

Secret storage should not add custom support for Optional, Union, or other type hints that are not supported by simtypes.from_string().

For parsing stored secret strings, skelet should follow the same practical limitation as environment variables: values are converted with the type-aware parser from simtypes, and the documented set of supported secret field types is intentionally narrow.

Supported secret field types

• str
• int
• float
• bool
• date
• datetime
• list with supported element types
• tuple with supported element types
• dict with supported key/value types

Any and missing annotations are interpreted like str, matching the environment variable behavior documented in README.md.

Explicitly unsupported for parsing stored secrets

• Optional[...]
• Union[...]
• T | None
• arbitrary custom classes
• other advanced typing constructs not supported by simtypes.from_string()

These annotations can still participate in ordinary Field behavior for defaults, source-provided values, and runtime type checking where existing skelet behavior allows them. The limitation here is specifically about parsing a string value returned by secret storage.

Stored null string

A secret storage returning Python None still means that the secret is absent.

A stored string value equal to null is not interpreted as Python None:

• for str and Any, it is the literal string 'null';
• for other supported non-string types, it is passed to the parser and fails if the parser cannot interpret it;
• for Optional[...], no special nullable parsing is performed.

Implementation impact

Remove local nullable-type helpers from skelet.secret_storage and avoid duplicating parsing logic that belongs to simtypes.

Keep only the secret-storage-specific behavior:

• backend None means absent;
• backend values must be strings;
• string fields are raw strings and are not JSON-decoded by skelet;
• parsing errors are re-raised with secret-aware, masked error messages.