feat(quests): track pokecoin rewards

[hokiepokedad2]

Extracted from the abandoned feat/poracleng-two-branch-support (preserved at 3d33b35). Independent of the other open PRs.

Quest alarms gain a sixth reward tab: pokécoins. It works the way stardust does — a minimum amount and no item selector — because Poracle matches this reward on the amount alone.

Verified by calling both servers, not by reading release notes

A throwaway human on each dev instance, one POST each:

	/health	reward_type: 8	reward_type: 3 control
5.1.0	5.1.0	400 {"message":"Unrecognised reward_type value","status":"error"}	200, stored
5.2.1	5.2.1	200, newUids:[519]	200, stored

Read back from 5.2.1:

{"reward_type":8,"reward":50,"amount":0,"description":"Reward: **50 or more pokecoins** "}

That confirms the stardust modelling: the floor travels in reward, amount stays 0, and Poracle renders it as "N or more". The test data has been removed from both servers.

Gating

This is the one capability with neither a column nor a flag behind it — PoracleNG only widened its validRewardTypes allowlist, so the version string is the only available signal. 5.2.1's /health map is {buttons, snapshots, autocreate, tomlDts, buttonResponseObject, derivedDtsTypes}; nothing about quests. The comment at the gate says so, since it is the exception to the otherwise-preferable rule of gating on the migration number.

Built on the existing pattern rather than a new one:

• IQuestPokecoinCapabilityService copied from the ISummaryCapabilityService shape, reading IPoracleServerProfileService (already cached five minutes, already fails closed). No cache of its own.
• AlarmValidationException, not a new exception type. Its global filter already produces 400 {error: "..."}, which is exactly what the add dialog's existing error handler surfaces. Upstream answers 400 for the same request, so the status is honest.
• GET /api/quests/capability → {pokecoins: bool}, mirroring GET /api/summary-schedules/capability, rather than a global capability list.

The registry from the abandoned branch — PoracleCapabilityKeys, IPoracleCapabilityService, PoracleCapabilityService, poracle-capabilities.ts and the /api/settings/poracle-capabilities endpoint — was deliberately dropped. It duplicated a convention this codebase already had.

An existing pokécoin rule stays usable on an old server

Someone may have set one with the bot. Reading and deleting are never gated — only creating. A row nobody can see is a row nobody can delete.

Tests

26 backend tests across two classes, plus the frontend spec. Every refusal is paired with a legitimate case: create/update/bulk refuse type 8 on an old server, and a [Theory] proves all five previously-valid reward types still write, a mixed batch with no pokécoin row still writes, and an existing pokécoin rule is still readable and deletable on that same old server. The version boundary is pinned — 5.1.0 and 5.0.9 false; 5.2.0, 5.2.1, 6.0.0 and 5.2.1-rc1 true.

Watched failing first: neutering the guard turned exactly the 3 refusal tests red and left the 11 legitimate-case tests green. On the frontend, forcing the @if false reddened the tab-count test and removing case 5 from save() reddened two more.

Housekeeping

All five i18n keys are in all eleven locales, actually translated using the official Pokémon GO currency names (PokéMünzen, Poképièces, PokéMonedas, PokéMonete, PokéMoedas, PokéMunten, PokéMonety, PokéMynt, PokéMønter) rather than English placeholders. The sibling quest-add-dialog.component.spec.ts mock needed pokecoinsSupported added and got it.

One dead-code note for the reviewer: isStardust on the edit dialog is now read only by its spec, since usesRewardSlot replaced it in the template. Kept because it pairs with the new isPokecoins, but happy to drop it.

Verification

Backend 2156 passed. Jest 104 suites / 1173 tests. ng build --configuration production, ng lint and prettier-check all clean.