Fix over-read when deserializing maps without type hint

Before this patch `deserialize_any_with_header` simply handed the outer
deserializer (`self`) to `visitor.visit_map()` whenever it met an
`ElementType::Object`.
Because `self` had no upper bound on how many bytes it could read, any
map situated inside another structure (array, enum, …) could carry on
past the current object’s `payload_size` and consume bytes that belonged
to the following elements.

Typical failure:

• `[{}, {}]` encoded as `0x2b 0x0c 0x0c`
  – first byte → array header
  – next two bytes → headers of two empty objects

The first object’s payload size is zero, so a correct implementation
should finish it immediately.
Instead the un-bounded map visitor tried to read a key, grabbed the byte
`0x0c` that actually started the second object and the decode crashed
(odd element count / trailing characters).

Internally-tagged enums (`#[serde(tag = "...")]`) break the same way
because they are encoded as objects inside larger containers.

Fix
1. For `ElementType::Object` create a new `Deserializer` whose reader is
   wrapped in `take(header.payload_size)`, and pass that to
   `visitor.visit_map()`.
2. Apply the same idea in `deserialize_enum`, also checking that the
   sub-reader is completely consumed before returning.

This confines every map visitor to the exact span of its object and
prevents accidental over-reads.

Tests added/updated
• Array of maps parsed as `serde_json::Value` (`[{}, {}]`).
• Single and multiple internally-tagged enum values.
• Miscellaneous nested-object scenarios inside SQLite integration tests.

Closes #5

WASM compatibility + fix large integer conversion issues + update deps

first release

alpha