fix(linux/wlgrab): add frame_timestamp using wayland's ready timestamp

[andygrundman]

Description

This PR adds frame_timestamp to the wlgrab backend, used with headless Wayland. The timestamp comes from Wayland's ready callback, which I think is the best place to take it from. I also added framerateX100 support since it's very simple.

I also wanted to make the logs a bit easier to understand across all the various Wayland code, so I added prefixes to all the logging. I also removed a couple logs from very hot callbacks.

I'll submit a future PR for wlgrab to ignore duplicate frames for variable fps.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[andygrundman]

cc @psyke83 Have you ever used the wlgrab backend?

[sonarqubecloud]

Quality Gate failed

Failed conditions
2 New issues
3.2% Duplication on New Code (required ≤ 2%)
2 New Code Smells (required ≤ 0)
8 Duplicated Blocks on New Code (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[ReenigneArcher]

I like this pattern. It would be nice if we could automatically include the source file and line number from where a log message was initiated. I don't know how hard it would be to implement in Sunshine, but I did something similar in our python discord bot recently.

2026-02-27 23:14:42 - src.common.database - [database.py:321] - INFO - Committed changes to git data repository
2026-02-27 23:14:43 - src.common.database - [database.py:329] - INFO - Pushed changes to remote git data repository
2026-02-27 23:18:58 - src.common.webapp - [webapp.py:297] - INFO - received webhook from github_status
2026-02-27 23:18:58 - src.common.webapp - [webapp.py:299] - INFO - received webhook data: 

In any event, it would be nice to have the capture method as a prefix for all the capture methods, whether on Linux, Windows, or macOS (even though there's only one on macOS right now).