Minor decode-path dispatch: unpackEnum and .custom keys go through generic layers

[lalinsky]

Two smaller items on the decode path, both from the same review as #31 and #32. Neither is likely to be worth much on its own; grouping them so they can be picked up together or dropped together.

unpackEnum routes through the full integer header switch. It builds an OptionalTagType and calls unpackInt, which runs the whole switch (header) over every int encoding, for what is nearly always a single fixint byte.

The .custom key path uses unpackAny for the key. In unpackStructFromMapBody:

const KeyType = comptime @typeInfo(@TypeOf(Type.msgpackFieldKey)).@"fn".return_type.?;
const key = try unpackAny(reader, allocator, KeyType);

unpackAny re-dispatches on @typeInfo(KeyType) for what is by convention a small integer. Calling unpackInt directly skips a layer. It would also mean msgpackFieldKey returning a non-integer stops silently working, so worth deciding whether that is intended to be supported at all.

For scale: the .as_array format, which removes map framing and keys entirely, decodes only 27% faster than .field_name on message, 13% on document, and 0% on event. Everything here lives inside the remainder, so expect low single digits at best. Measure before and after.

[lalinsky]

Closing unmeasured — the expected payoff does not justify the churn, and the surrounding measurements bound it well enough to say so without building it.

.as_array, which removes map framing and keys entirely, decodes only 27% faster than .field_name on message, 13% on document, and 0% on event. That is the ceiling for everything to do with key handling. Both items here sit inside the remainder after that:

• unpackEnum routing through unpackInt's full header switch for what is nearly always one fixint byte
• the .custom key path calling unpackAny rather than unpackInt directly

The two changes that did land this round were measurable because they removed work on every field (#38, ~20 instructions per optional field) or every string value (#43, ~8-20 instructions per string). These two would remove a few instructions from a subset of one key mode and one type, on shapes where key handling was already shown not to dominate.

There is also a cost side. The .custom change would mean msgpackFieldKey returning a non-integer stops working, which is currently accidental but might be relied on. Deciding whether that is supported is a bigger question than the optimization is worth.

Reopen if a profile ever points here specifically. The rig for answering it exists now — one library version per binary, callgrind instruction counts, non-participating controls to confirm the delta is real — so it would be quick to settle properly rather than by eye.