fix(aws-lambda): accept lowercased secret-token header for HTTP API

[glacierphonk]

Summary

Follow-up to #896. The awsLambda and awsLambdaAsync adapters in src/convenience/frameworks.ts read the X-Telegram-Bot-Api-Secret-Token header with a case-sensitive lookup against the title-case constant. That works under API Gateway REST API (payload 1.0), which preserves the original client header case, but fails under API Gateway HTTP API (payload 1.0 or 2.0), which lowercases every inbound header name. Users on HTTP API with a configured secretToken had every update rejected 401, because event.headers["X-Telegram-Bot-Api-Secret-Token"] is undefined when the actual key is "x-telegram-bot-api-secret-token".

AWS documents the HTTP API lowercasing in the payload format structure:

The following examples show the structure of each payload format version. All headernames are lowercased.

REST API users were and are fine; I need them to stay fine.

What changed

 const awsLambda: LambdaAdapter = (event, _context, callback) => ({
     get update() {
         return JSON.parse(event.body ?? "{}");
     },
-    header: event.headers[SECRET_HEADER],
+    header: event.headers[SECRET_HEADER] ??
+        event.headers[SECRET_HEADER_LOWERCASE],

Identical change in awsLambdaAsync. Title-case lookup first (REST API), lowercase fallback second (HTTP API). Both constants already exist at the top of the file and are used by other adapters.

No type changes — LambdaAdapter / LambdaAsyncAdapter already declare headers: Record<string, string | undefined>.

Coverage matrix

Integration	Payload	Header casing delivered	Before	After
REST API	1.0	X-Telegram-Bot-Api-Secret-Token	works	works
HTTP API	1.0	x-telegram-bot-api-secret-token	401	works
HTTP API	2.0	x-telegram-bot-api-secret-token	401	works

Test plan

• deno check --allow-import src/mod.ts — clean
• deno task test — 38 suites, 443 steps, all pass
• Manual smoke for both adapters:
  • title-case key → returns value (REST API path)
  • lowercase key → returns value (HTTP API path)
  • missing header → returns undefined
• Verified on a live Lambda deployment (not required for merge; happy to do so if you want).

Context

cc @KnorpelSenf — you green-lit this follow-up in #896. Same reasoning, different adapter pair.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 44.17%. Comparing base (b04bfee) to head (aa042f2).
⚠️ Report is 120 commits behind head on main.

Files with missing lines	Patch %	Lines
src/convenience/frameworks.ts	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #900      +/-   ##
==========================================
- Coverage   45.52%   44.17%   -1.36%     
==========================================
  Files          19       19              
  Lines        5520     6694    +1174     
  Branches      360      463     +103     
==========================================
+ Hits         2513     2957     +444     
- Misses       3003     3651     +648     
- Partials        4       86      +82     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KnorpelSenf]

Why does REST API 1.0 still work after this change, given that there is now a mismatch in casing?

[KnorpelSenf]

Ah hold on, looking at the diff helped, nevermind