Make Payload case-insensitive — single streaming pass (Fixes #108)

[russ]

Problem

Fixes #108.

Crystal's JSON parsing is case-sensitive, so a payload like {"Command": "Subscribe"} failed two ways:

1. Field name — Payload.from_json raised Missing JSON attribute: command because the key was Command, not command.
2. Command value — Connection#receive dispatched on payload.command == "subscribe", so a Subscribe value never matched.

Approach (and why not the obvious one)

Payload.from_json is the hot path — it runs for every inbound frame — so it has to stay fast. The tempting fix (parse the message into a JSON::Any tree, lowercase the keys, re-serialize, re-parse) is ~2.8× slower with ~2.5× the allocations, which isn't acceptable here.

Instead, this keeps the protocol keys as regular JSON::Serializable fields, so a correctly-cased message is matched directly in a single streaming pass with no extra work. A mis-cased key isn't matched, so it falls through to on_unknown_json_attribute, where String#compare(case_insensitive: true) matches it without allocating a downcased copy of the key — all still within the one pass, no re-parsing.

• command / identifier become nilable internally so a mis-cased-only key isn't rejected by the "Missing JSON attribute" check before we can capture it. The public accessors re-enforce presence, so a genuinely missing command/identifier still raises JSON::SerializableError (now at access, still caught by Cable::Handler).
• data (read from json_unmapped) is captured under its lowercase key the same way.
• Connection#receive matches the command value case-insensitively with the same allocation-free compare.

Benchmark

Parsing a typical payload, vs the original case-sensitive parse:

Approach	Throughput	Alloc/op
original (case-sensitive)	1.53M/s	1.07 kB
tree rebuild (rejected)	~0.53M/s	2.71 kB
this PR — correctly-cased	1.48M/s	1.07 kB
this PR — mis-cased	1.33M/s	1.07 kB

The happy path is within ~3% of today's parse with identical allocations; a mis-cased payload is ~15% slower with no extra allocation.

Tests

• Payload parses mixed-case top-level keys ("Command", "Identifier", "DATA").
• A genuinely missing command still raises JSON::SerializableError.
• End-to-end #receive accepts {"Command": "Subscribe", "Identifier": ...} and confirms the subscription.

Green locally on Crystal 1.10.0 and current stable.

Note

The nightly CI job is continue-on-error: true and fails repo-wide because ameba won't compile against Crystal nightly — unrelated to this change.

[jwoertink]

Instead of doing this, we can add an after_initialize method that just does @command = @command.downcase. That gets set in the Payload

[jwoertink]

This is going to be a fairly large performance hit... I have a feeling that at the moment, this isn't really possible in Crystal without doing this method here.

JSON::Field supports a key option where you can do @[JSON::Field(key: "Command")], but now the lowercase version doesn't work. A "hacky" method would be to define both a @command : String? and @Command : String? then an instance method command which chooses one or the other 😂 but.... gross lol.

What would be cool is if the annotation allowed for a regex or something, but that would require a new feature added to Crystal. Maybe for now just having the command set to lowercase is a decent enough update and we just make sure to document that the key "command" must also be lowercase?