Fix/jwt signature verification

[Benedict315]

Description

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🔧 Refactoring (no functional changes)
• ⚡ Performance improvement
• 🧪 Test addition or update

Related Issues

Closes #

Changes Made

Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed

Test Steps

Breaking Changes

Breaking Changes:

Migration Guide:

Screenshots/Demo

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published
• I have checked for breaking changes and documented them if applicable

Additional Notes

closes #632

[ogazboiz]

this is security-sensitive so i looked closely, and it can't land as-is:

1. there are unresolved git merge-conflict markers committed into backend/src/middleware/auth.ts (~lines 118-135), which fails tsc everywhere.
2. more seriously, the "ours" side of that conflict is an auth-bypass: it references vars that don't exist (providedSig/expected instead of the actual ...Buf names), and crypto.timingSafeEqual throws on a length mismatch into a catch that does NOT return null, so a token with a wrong-length signature gets ACCEPTED. that's a real vulnerability.
   please resolve the conflict by keeping the main side (which length-checks before timingSafeEqual and returns null correctly) and drop this pr's comparison logic. the intent (hardening verifyJwt) is right, the implementation just must not weaken it. also note this near-duplicates your #985, keep the a11y in #985 and just the (corrected) jwt work here.