Add unit tests for QR access-check payload validation edge cases

[Lakes41]

Difficulty: Intermediate
Type: test

Background
The README documents a strict QR access-check payload schema (type, version, guildId, resourceId required; walletAddress, expiresAt optional) and states that unsupported types/versions, malformed JSON, missing required fields, invalid wallet addresses, and expired payloads are all rejected before submission — this logic lives in src/features/access/.

Problem
It's not clear this validation matrix has full unit test coverage; without it, a future refactor of the QR parsing/validation code could silently regress one of the documented rejection cases (e.g., accepting an expired payload).

Expected outcome
The QR payload validator has a unit test for every documented rejection case (bad type, unsupported version, malformed JSON, missing guildId/resourceId, invalid walletAddress, expired expiresAt) plus the happy path (valid payload with and without optional fields).

Suggested implementation

• Locate the QR payload validation function in src/features/access/ and add a dedicated test file under tests/ if one doesn't fully cover this matrix.
• Write one test case per documented rejection reason, asserting a specific, distinguishable error/result (not just a generic false).
• Add a test confirming a valid payload without the optional walletAddress/expiresAt fields still passes.
• Run pnpm test:run to confirm all pass.

Acceptance criteria

• Every rejection case listed in the README has a corresponding test
• Valid payloads with and without optional fields both pass
• Each rejection case produces a distinguishable, specific result (not one generic failure)
• pnpm test:run and pnpm typecheck pass

Likely affected files/directories

• src/features/access/
• tests/

[jchinedu]

Hi! I'd like to work on this issue.

I have experience writing TypeScript applications and adding unit tests for validation logic to ensure expected behavior is preserved during future refactors. I understand the importance of thoroughly testing input validation, especially for security- and access-related features like QR payloads.

For this issue, I'll identify the existing QR payload validator and add a dedicated test suite covering every documented validation scenario, including malformed payloads, unsupported versions, missing required fields, invalid wallet addresses, expired payloads, and the expected success cases with and without optional fields. I'll also make sure each failure case returns a clear, distinguishable result rather than a generic validation error.

I'd be happy to contribute a clean, well-tested implementation that follows the project's existing testing conventions.

[grantfox-oss]

🦊 GrantFox — @jchinedu has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #232)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.