refactor(core): replace any types with unknown in useStorageState

[guesung]

Summary

• Replace any with unknown in SerializableGuard, isPlainObject, and ensureSerializable type definitions
• Replace any with string in test serializer/deserializer parameters to match the hook's option types
• Aligns with the project's no-any coding standard

Test plan

• Type check passes (yarn run test:type)
• All 48 useStorageState tests pass

[Copilot]

Pull request overview

This PR continues the repo’s strict TypeScript goal of eliminating any by updating useStorageState’s internal type utilities and aligning related tests/docs.

Changes:

• Replaced any with unknown in SerializableGuard, isPlainObject, and ensureSerializable typings in useStorageState.
• Updated the useStorageState custom serializer/deserializer test to use string parameters.
• Fixed useMap documentation code fences and added a missing import in the example.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/hooks/useStorageState/useStorageState.ts	Replaces any with unknown in internal helper typings for serializability checks.
src/hooks/useStorageState/useStorageState.spec.ts	Updates test serializer/deserializer parameter types to string.
src/hooks/useMap/useMap.md	Cleans up markdown code fencing and improves the example snippet.

Comments suppressed due to low confidence (1)

src/hooks/useStorageState/useStorageState.ts:28

• SerializableGuard’s conditional type is effectively a no-op: T[0] extends unknown is always true (including never), so the 'Received a non-serializable value' branch is unreachable. If the goal is to surface a helpful type-level message when Serializable<T> collapses to never, rewrite the conditional to check for never first (or remove the guard entirely if it’s not needed).

type SerializableGuard<T extends readonly unknown[]> = T[0] extends unknown
  ? T
  : T[0] extends never
    ? 'Received a non-serializable value'
    : T;

[Copilot]

In this test, serializer/deserializer are typed as (value: string) => ..., but their implementations still branch on non-string primitives and call JSON.parse, which returns any and can produce non-string values. This makes parts of the logic unreachable by type and weakens the intent of aligning types; either simplify the functions to be truly string-only, or broaden the types (and the test inputs) to exercise non-string serialization/deserialization without reintroducing any via JSON.parse.

[zztnrudzz13]

Thank you very much for your contribution.

However, since the value parameter is not limited to a string type, narrowing it down to string does not seem appropriate. Additionally, this hook has been deprecated and is no longer planned to be maintained, so we will be closing this issue.

That said, we truly appreciate your contribution and effort.