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.