fix(linux/kwin): explicitly cleanup screencast_t allocated memory resources to ensure nothing is leaking

[Kishi85]

Description

In #5346 a memory leak in pipewire-based capture methods (portalgrab, kwingrab) was identified.

This PR is a (first) step to fix potential causes in kwingrab by explicitly calling:

• reset() on any created shared_ptr instances in screencast_t
• clear() on used lists/maps in screencast_t

during destruction to ensure associated resources are always properly released.

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

[Kishi85]

In theory this PR shouldn't make a difference as C++ should manage memory for those types (std::shared_ptr, std::map, std::vector) by itself correctly for how they are used in kwingrab.

@psyke83 maybe you can check if it makes a difference on your end as my tests are a bit inconclusive right now...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Doing more testing and also cleaning up pipewire's destructor a bit but so far no luck with the memory leak. It's almost a stable ~16MB increase per full capture re-init for both kwingrab and portalgrab so the culprit is likely somewhere in pipewire.cpp or related to the pipewire code used overall.

Almost forgot: If I can't find the source of the leak myself I'll change this PR to do some code maintenance (like rolling 'cleanup_stream()` into the destructor as it's not used anywhere else anymore und updating a few unnecessary things based on CLion/Sonar suggestions).