Add opt-in quest task filtering

[DannyM300]

Summary

Add an opt-in Tasks tab to quest filters so users can select quests by task, with optional narrowing to particular rewards.

This was requested by users who wanted to find a task directly rather than first selecting every reward that task may currently grant.

Behaviour

Task filters use a stable k<title>-<target> key and support:

• enabling or disabling a complete task;
• narrowing a task to selected rewards through the advanced dialog;
• retaining the existing inverse workflow where a reward can be narrowed to selected task conditions.

Reward-first and task-first filters are additive: a quest is included when either its reward filter or its task filter matches.

Task filters default to off, so adding the feature does not keep quests visible unexpectedly or change existing reward-filter defaults. Users opt into task matching from the new tab.

SQL and Golbat support

Task-to-reward mappings are generated on both available-data paths:

• SQL-backed PokéStop availability;
• Golbat /api/fort/available.

For Golbat DNF queries, enabled task keys are expanded into the reward keys that task can grant before translation. A task narrowed through its advanced settings expands only to the selected rewards. The SQL/in-memory path performs the equivalent task-and-reward match directly.

Task conditions are exposed with the available map data and used to build translated/searchable entries in the drawer.

The virtualised selector grid is mounted only while its tab and drawer are visible. This prevents the new Tasks grid reopening with stale hidden-container measurements.

Profile note

The feature itself is independent of profile storage. However, every dynamic task adds another default filter entry to the merged client filter tree, which can make existing full-state profile payloads considerably larger on maps with many tasks.

The general profile payload compaction is therefore submitted separately in #1239 so it can be reviewed independently and, ideally, merged before or alongside this feature.

Validation

• Implemented as one standalone commit on current upstream main (8ce212ff).
• Contains no Rocket identity or profile-storage changes.
• All 19 focused task matching, advanced narrowing and Golbat DNF expansion tests pass.
• Production Vite build succeeds (2,374 modules transformed).
• Manually tested task/reward filtering using both SQL and Golbat-backed available data.

Happy to adjust the key format, API shape or UI placement if the maintainers prefer another approach.

[Mygod]

This explanation makes no sense to me. Also do you have a screenshot?

[DannyM300]

Basic terms it allows selection by task instead of via reward, which is beneficial in the new event structure and for hard core grinded who are task stacking.

[Mygod]

And what's the use case?

[DannyM300]

Cutting down interactions for farming task completion selection options. As seen image above you could select the quest for 3 great throws, to stack them to complete all at once with the easier quests. A lot of hard core grinders manually set this up currently via each reward options, switching this to task side allows quick selection. This is extremely time consuming to set up.

New example using current events of usefulness to the main userbase and not just the hard core grinders -

Users note they skip the 2km tasks alot & only push ahead on the spin 10 poke stops or gyms, current selection would be multiple clicks on each Pokémon and selection of tasks to get the same results, as 1 click would in this inverse selection option.

[Mygod]

So it sounds like you are just chasing the boosted-odds event quests. Given that there are just a few for each event, the currently supported path just requires a few clicks to set up. On the other hand, the long term complexity for both the codebase and end user does not appear to be worth it: the UI is unintuitive and difficult to grasp for the uninitiated and the filtering complexity further muddies the logic.