Fix critical webhook signature case bug; add correlationId + AR type registration

Strike sends X-Webhook-Signature in UPPERCASE hex. OpenSSL::HMAC.
hexdigest always returns lowercase, and valid_signature? compared them
case-sensitively via secure_compare — every genuine Strike webhook was
being silently rejected as an invalid signature. Confirmed live: executed
a real Lightning payment (payment-quotes/lightning + PATCH .../execute),
received a real payment.updated webhook, and recomputing the HMAC over
the captured payload/secret matched case-insensitively but not
case-sensitively — proving the algorithm/secret/body were already
correct and this was purely a case-comparison bug. Their own reference
docs (docs.strike.me/webhooks/signature-verification) don't mention the
case difference. Regression test added using the real captured signature,
upcased.

Also, both found via that same live test:
- Invoices::Invoice didn't declare correlationId, raising
  ActiveModel::UnknownAttributeError the moment a real one (which
  CreateInvoice always sends) round-tripped through a live response —
  no existing spec fixture's stubbed body had included it.
- BtcAttributeType was only registered with ActiveModel::Type, not
  ActiveRecord::Type (a separate registry) — an `attribute :x,
  :strike_btc` declaration on an ActiveRecord model raised "Unknown
  type" without this. Guarded behind defined?(ActiveRecord::Type) since
  this gem only depends on active_model.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

lib/strike_me/api/webhook.rb

@@ -22,7 +22,18 @@ module StrikeMe
         return false if signature.blank? || raw_body.blank?
 
         expected = OpenSSL::HMAC.hexdigest('SHA256', secret, raw_body)
-        secure_compare(expected, signature)
+        # Strike sends X-Webhook-Signature in UPPERCASE hex — confirmed
+        # live against a real webhook delivery (payment.updated, a real
+        # executed Lightning send) 2026-09-22. OpenSSL::HMAC.hexdigest
+        # always returns lowercase. Without downcasing both sides here,
+        # secure_compare's case-sensitive byte comparison rejected every
+        # genuine Strike webhook as an invalid signature — silently: a
+        # rejected webhook looks identical to an actual forgery attempt
+        # from the outside, so this would have broken settlement in
+        # production with no visible error at all. Their own docs'
+        # reference implementation (docs.strike.me/webhooks/
+        # signature-verification) doesn't mention this case difference.
+        secure_compare(expected.downcase, signature.downcase)
       end
 
       # ActiveSupport::SecurityUtils.secure_compare raises on a length