security: add authentication to logs endpoint and filter by user

[cfsmp3]

Summary

• Add session authentication to /sync/logs endpoint
• Filter logs by user UUID so users can only see their own logs
• Return 401 Unauthorized for unauthenticated requests

Security Issue Addressed

Unauthenticated Logs Endpoint (Medium) - Previously, the /sync/logs endpoint had no authentication, allowing anyone to view sync operation logs. Logs could contain sensitive information like user UUIDs and operation details.

Changes

• backend/controllers/get_logs.go:

  • Require valid session to access endpoint
  • Pass session store to handler
  • Filter logs by authenticated user's UUID

• backend/models/logs.go:

  • Add GetLogsByUser() method to filter logs by SyncID (user UUID)

• backend/main.go:

  • Update SyncLogsHandler call to pass session store

Test plan

• Test authenticated users can view their own logs
• Verify unauthenticated requests return 401
• Verify users cannot see other users' logs

🤖 Generated with Claude Code

[github-actions]

Thank you for opening this PR!

Before a maintainer takes a look, it would be really helpful if you could walk through your changes using GitHub's review tools.

Please take a moment to:

• Check the "Files changed" tab
• Leave comments on any lines for functions, comments, etc. that are important, non-obvious, or may need attention
• Clarify decisions you made or areas you might be unsure about and/or any future updates being considered.
• Finally, submit all the comments!

More information on how to conduct a self review:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request

This helps make the review process smoother and gives us a clearer understanding of your thought process.

Once you've added your self-review, we'll continue from our side. Thank you!

[its-me-abhishek]

should also add a cap to the last value. one may request for a pretty big number which can cause crashes. Also maybe just maintain the same threshold, overall as well. To prevent unnecessary overheads

[its-me-abhishek]

A hard cap of 20 should probably be enough

[cfsmp3]

Addressed the feedback in commit ccba488:

• Changed default from 100 to 20
• Added hard cap of 20 entries - even if user requests more, they get max 20
• This prevents resource exhaustion from large requests

The cap is enforced with a simple check after parsing the parameter.