fix: use on_primary theme color for sync and bump plugin_api for noct…

[ChristPetitjean]

…alia.getColor support

Plugin

• Id: <author>/<plugin>

• New plugin
• Update to an existing plugin (version bumped in plugin.toml)

What it does

Use noctalia.getColor("on_primary") to support dynamic wallpaper color extraction and better contrast.
Added Pywal/Wallust fallback for CachyOS users.

External dependencies

Testing

• Tested on Niri
• Tested on Hyprland
• Tested on Sway
• Tested on another compositor:
• Noctalia version tested against:
• **Plugin API level:31

Screenshots / Videos

Checklist

Ready-for-review requirement: Every box in this section must be checked. If any statement is not true, keep the
pull request as Draft. An explanation does not replace a required check.

• The directory name matches the part of id after the / in plugin.toml exactly.
• It ships plugin.toml, README.md, thumbnail.webp, and translations/en.json.
• README.md follows the
  README template, documents
  every entry id and dependency, and includes exact panel IPC commands and launcher prefixes where applicable.
• thumbnail.webp is present and relevant; for a new plugin I created it with the thumbnail generator, and for an update I regenerated it with the generator if the visual identity or user-facing appearance changed.
• version follows semver and is bumped in this PR; plugin_api is the oldest API level this plugin requires.
• Every non-English translation in this PR uses a locale supported by Noctalia core, and I can read, write, and
  understand that language well enough to review and maintain it (no unreviewed machine/LLM translations).
• I did not edit catalog.toml; CI generates it.
• This PR touches exactly one plugin directory.

Code review attestation

Plugins run as trusted, unsandboxed Luau in the user's session. Confirm:
Ready-for-review requirement: Every attestation below must be checked.

• The code is readable and not obfuscated, minified, or generated.
• It does not download and execute remote code.
• Every network call, filesystem write, and spawned process is something the description above accounts for.
• I have the right to publish this code under the license declared in plugin.toml.

[Noctalia-CI]

This pull request was converted to a draft because its description is missing required
parts of the pull request template.

Missing:

• the - **Plugin API level:** field

Add the items above to the description, keeping their exact wording, then mark the pull
request ready for review. Draft pull requests may leave boxes unchecked. Before a pull
request is ready for review, exactly one plugin type, at least one tested compositor, and
every item under Checklist and Code review attestation must be checked.

Sections that only offer context may be deleted; nothing else about this pull request was
changed.

[Noctalia-CI]

CC @detluck: this pull request was automatically moved to draft until you have had a chance to look at it. It will be marked ready for review automatically once you reply here.

[detluck]

I actually wanted to use noctalia.getColor() for this, but I am on vacation and didn't get around to updating it.

I think we can simplify the implementation by using the native Noctalia API instead of adding Pywal/Wallust fallbacks. Since noctalia.getColor() already returns the active theme's resolved color, reading colors from ~/.cache/wal/colors doesn't really add anything for Theme Sync. It also assumes that the user has Pywal, Wallust, or a compatible tool installed, which not everyone does. For example me.

It could also lead to the Razer lighting using a color that doesn't match the current Noctalia theme if the cached Pywal colors are from a different wallpaper/theme.

The built-in palette fallback should also be unnecessary for the same reason getColor() handles the active theme directly.

I'd suggest keeping it simple: use noctalia.getColor() and fall back to Razer Green only if Noctalia can't provide the requested color.

P.S. I also think a selector for which theme color to sync would be a really nice addition. For example, letting the user choose between primary, secondary, tertiary, surface, on_surface, etc. That way the user can decide exactly which Noctalia theme role should control the Razer lighting. But it's not necessary to do it now. I could implement it later.

[Noctalia-CI]

This pull request was converted to a draft because its description is missing required
parts of the pull request template.

Missing:

• the - **Plugin API level:** field

Add the items above to the description, keeping their exact wording, then mark the pull
request ready for review. Draft pull requests may leave boxes unchecked. Before a pull
request is ready for review, exactly one plugin type, at least one tested compositor, and
every item under Checklist and Code review attestation must be checked.

Sections that only offer context may be deleted; nothing else about this pull request was
changed.