add positional highlighting driven by the next weaponskill

[ColdCoffee83]

What this adds

An opt-in mode that colours the guidelines by whether the next weaponskill actually wants that side of the target, instead of by a fixed per-direction colour. The correct cone gets one colour, every other side gets another, and they swap as the correct positional changes.

Optionally it also shades in the area the guidelines enclose, so the correct cone reads as a solid wedge rather than something you infer from which lines changed.

It defaults to off, so nobody's existing colours change when they update.

Coverage

All six jobs that have positionals. Each one reads whatever state actually settles the choice, rather than guessing at a rotation:

Job	Rear	Flank	Read from
Dragoon	Chaotic Spring, Wheeling Thrust	Fang and Claw	combo state
Monk	Demolish	Snap Punch / Pouncing Coeurl	coeurl form + MNKGauge.CoeurlFury
Ninja	Aeolian Edge	Armor Crush	combo state + NINGauge.Kazematoi
Reaper	Gallows	Gibbet	Soul Reaver window + Enhanced Gibbet/Gallows
Samurai	Gekko	Kasha	combo state
Viper	Hindsting / Hindsbane	Flanksting / Flanksbane	combo state

Anywhere the next weaponskill has no positional - a different job, the wrong point in a combo, a reaper with neither Gibbet nor Gallows enhanced - it returns None and the guides fall straight back to the existing per-line colours. Current behaviour is untouched on every path that isn't actively highlighting something.

On the awkward cases

Most of these are fully deterministic. Three needed a judgement call, and I'd rather flag them than have them found in review:

Monk's Perfect Balance suppresses the form status, so there's nothing to read. It's behind its own toggle, defaulting to highlighting the rear: Demolish is the coeurl-chakra filler, and nothing else pressed inside that window has a positional at all, so the rear is never the wrong place to stand.

Ninja's Kazematoi threshold. Aeolian Edge and Armor Crush are the same combo step and both are always usable, so which one is "correct" is a resource call rather than a hard requirement. Armor Crush grants two against a cap of five, so the code spends at four or more and builds at three or fewer. That's the standard line, but it is a line, and it's a named constant if you'd want it moved into config.

Reaper with neither Gibbet nor Gallows enhanced hits for the same either way, so it returns None rather than inventing a preference.

Monk is worth a note too: as of Dawntrail its positionals are only in coeurl form. Leaping Opo, Dragon Kick, Rising Raptor and Twin Snakes have no positional line left in their descriptions. I checked every positional here against the live action data rather than working from memory, which is the only reason that came up - my own first instinct had monk with six.

Structure

Positionals.Detect dispatches on job id and returns a RequiredPositional (None / Rear / Flank). The rendering path only ever sees that enum, so a job is one private method and one switch arm; nothing job-shaped reaches the drawing code.

Dragoon's action list includes the pre-upgrade ids (Disembowel, Chaos Thrust, Full Thrust) so it still works below max level.

One rendering note

The shading is a triangle fan around the target. Its segments share their edges exactly, so it draws with AntiAliasedFill cleared and the flag restored immediately afterwards. Without that, each triangle's AA fringe blends over its neighbour's and you get faint spokes radiating out of the target.

Also added

• Config section with colours for the correct/incorrect sides, the Perfect Balance toggle, whether the diagonal guidelines count as part of the cone they bound or only the cardinal line through the middle does, whether the circles recolour to match, and the shading toggle plus an opacity slider.
• /posguide toggle positionals and /posguide toggle fill, documented in the existing command help section.

Testing

Builds clean against API 15 with no new warnings. Played on monk with it on - the colours flip on the correct GCD and the shading tracks the target properly. The other five are verified at the data level (positional requirements and combo prerequisites pulled from the live sheets, and the compiled constants checked back against them) but I've only put monk through actual combat, so a second pair of eyes on the others would be welcome.

Heads up, unrelated to this PR

pr-test.yml uploads from PositionalGuide/bin/release/portable/PositionalGuide, but the build puts the packaged output at PositionalGuide/bin/release/PositionalGuide. With if-no-files-found: error that step fails. I checked master unmodified and it produces the same layout, so this predates the PR and isn't something I introduced - just flagging it so a red X on the checks doesn't send you looking in the wrong place. I left the workflow alone since it isn't mine to change here.

Disclosure

Written with AI assistance (noted in the commit trailers as well). The game-data claims above were checked against the live action and status sheets rather than recalled, and the Dalamud API surface used here was verified against the shipped assemblies.

[VariableVixen]

Sorry, but I don't think I can merge this. I'm pretty sure this would take the plugin beyond what the main repo guidelines allow, by going from simply providing information that already exists to performing logic for the player. I'd have to take this off the main repo and move it to being a third-party plugin, and not only do I not want to do that, there's already a third-party plugin to do exactly what you're proposing.

However, I very much appreciate the point about the workflow! I was messing around with some ideas a while back and thought I'd reverted everything, but apparently not.