feat(player): add directional combat dash

[f1cklepickle]

Why

• Player survival needs an active repositioning option for evading committed attacks and escaping pressure.
• The dash must work consistently across desktop, gamepad, and mobile without taking ownership from the existing movement, facing, defense, attack-cancellation, or virtual-gamepad systems.
• This issue delivers the focused player-dash vertical slice; generalized enemy displacement and progression systems are deferred.

Gameplay Contract

Ownership and lifecycle

• Add a focused dash component/runtime as the single authoritative owner of dash state and tuning.
• A dash request succeeds only when the dash is idle, cooldown is ready, and the player is not guarding, parrying, or in defense recovery.
• Snapshot and normalize the dash direction when activation succeeds. The active dash cannot be steered.
• Cooldown begins when the dash successfully starts.
• Movement input may continue updating during the dash so normal control resumes cleanly afterward.
• Do not buffer rejected dash input in the first version.
• Dashing does not rotate the player. Existing aim, facing, and defense-facing systems remain authoritative.
• Dash itself deals no damage.

Desktop

• Bind Dash to Left Ctrl.
• With meaningful WASD movement input, dash in the normalized movement direction.
• With neutral movement input, dash straight backward relative to the player’s current facing direction.

Gamepad

• Bind Dash to left-stick click / L3.
• With meaningful left-stick input, dash in the normalized movement direction.
• With neutral movement input, use the same straight-back dodge relative to current facing.

Mobile

• Do not add a dedicated dash button.
• Integrate the request with release of the captured movement stick through the existing virtual-gamepad/Input System path.
• Request a dash only when the stick is released while its normalized magnitude is at or above the configurable outer dash threshold; use the release direction.
• If the stick moves below that threshold before release, releasing it must not dash.
• Reaching the outer threshold earlier in the gesture must not arm a later dash after the stick returns inward. Evaluate the release sample, not historical peak magnitude.
• Final floating-joystick presentation belongs to feat(input): refine responsive floating mobile joysticks #287 and is out of scope.

Direction, Speed, Duration, and Derived Distance

• Normalize directional input so diagonal movement does not gain speed or distance.
• Classify the snapshotted direction relative to current facing using a broad rear hemisphere rather than exact eight-way sectors.
• Dash speed is identical in every direction. Backward dashes must not move more slowly than forward or lateral dashes.
• Forward, forward-diagonal, left, and right directions use full dash speed for the full dash duration.
• Straight backward, back-left, back-right, and other directions broadly behind the player use the same dash speed for a shorter active duration.
• Default rear duration/distance multiplier is 0.60.
• Calculate full distance from the authoritative values: dash distance = dash speed × full dash duration.
• Calculate rear duration as full dash duration × rear multiplier, then derive rear distance from the same speed: rear dash distance = dash speed × rear dash duration.
• With the default 0.60 multiplier, rear duration and distance are 60% of full duration and distance while speed remains unchanged.
• Neutral desktop/gamepad activation resolves straight backward and therefore uses the rear duration.

Authoritative Tuning

Keep these values inspector-tunable under the single dash owner:

• Dash speed.
• Full dash duration.
• Rear dash duration/distance multiplier; default: 0.60.
• Cooldown.
• Invulnerability duration, independently tunable from full or rear dash duration.
• Mobile outer release threshold.

Do not independently author normal or rear dash distance. Distance is always derived from dash speed and the selected active duration.

Future upgrade compatibility

• Keep dash speed cleanly exposed as one authoritative gameplay value so future progression can increase it without rewriting dash direction or state logic.
• Do not implement progression, upgrades, or stat scaling in feat(player): add directional combat dash #263.

Combat and State Interaction

• Starting a valid dash cancels any active attack through the existing attack-reset/cancellation path.
• Clear held attack input so attacking does not immediately resume after the dash.
• Dash cannot begin while guarding, parrying, or in defense recovery.
• While dashing, reject attack, defense, repair, potion use, and another dash.
• Preserve live movement-input updates during dash.
• Do not chain dashes or buffer a rejected dash.
• Exit must restore normal movement cleanly without stale dash velocity, movement, or action state.

Invulnerability

• Damage immunity begins only on the successful transition that starts the dash.
• Invulnerability duration is independently inspector-tunable and uses its own timer.
• Do not derive or scale i-frame duration from dash distance, full duration, rear duration, or the rear multiplier.
• A rear dodge may finish moving before its configured invulnerability window ends.
• Solid collision does not cancel the active dash state or shorten configured invulnerability timing.
• Invulnerability ends according to its configured timer, including when movement is blocked.

Collision Behavior

• Use the existing collision-aware player movement path.
• Do not teleport, disable colliders, phase through solids, or bypass the current collision system.
• Walls, Vault, barriers, and other solid geometry clamp displacement without cancelling dash state.
• When blocked by a wall, the dash remains active for its remaining directional duration while movement is blocked.
• Preserve natural sliding along any unblocked axis already supported by the current mover.
• Dash exit must not leave stale movement/state or create a dash-specific unrecoverable stuck state.
• Preserve existing player/enemy collision behavior unless a minimal dash-specific compatibility change is required.
• Do not add a generalized enemy-displacement, weight-comparison, knockback, heavy-enemy, or enemy-physics system in this PR.
• Weight-based dash displacement may be handled in a future focused issue.

Boundary with #276

• fix(player): prevent sticking against barrier and vault colliders #276 owns the broader investigation into existing player-collider sticking.
• feat(player): add directional combat dash #263 owns prevention of dash-specific sticking, tunneling, stale input/state, and broken recovery.
• Make only narrowly required collision changes for dash compatibility.
• Do not redesign PlayerCollisionMove2D, collider geometry, barrier/Vault seams, or normal movement collision behavior.
• If validation reproduces a pre-existing normal-movement collision problem, document it and leave the general fix to fix(player): prevent sticking against barrier and vault colliders #276.

Architecture and Scope

• Prefer a focused dash component/runtime/state owner rather than adding dash state to PlayerController.
• Preserve the movement/facing architecture established by PR feat(player): add post-aim facing grace before movement override #290.
• Preserve PlayerMovementOrchestrator as the normal velocity-input owner.
• Preserve PlayerFacingPolicyResolver as facing-source authority.
• Preserve PlayerFacingOrchestrator as facing execution authority.
• Preserve the existing defense state machine.
• Preserve existing attack cancellation/runtime contracts.
• Preserve the mobile virtual-gamepad abstraction.
• Keep feat(input): refine responsive floating mobile joysticks #287’s floating-joystick presentation, fix(player): prevent sticking against barrier and vault colliders #276’s general collider investigation, refactor(player): split PlayerController responsibilities #112’s broader controller refactor, generalized enemy displacement, and player progression out of scope.

Acceptance Criteria

• Left Ctrl activates dash on desktop and L3 activates dash on gamepad.
• Meaningful desktop/gamepad movement input selects a normalized dash direction.
• Neutral desktop/gamepad input performs a straight-back dodge relative to current facing.
• Mobile requests dash only when the captured movement stick is released at or above the configured outer threshold, using the release direction.
• Pulling the mobile stick below the threshold before release produces no dash, regardless of an earlier outer throw.
• Dash direction is snapshotted on successful activation and cannot be steered.
• Cardinal and diagonal direction inputs are normalized.
• Forward, diagonal, lateral, and rear directions all use the same authoritative dash speed.
• A backward dodge is not slower than a forward dash.
• Forward and lateral directions use the full dash duration.
• Directions in the broad rear hemisphere use the reduced duration with a default multiplier of 0.60.
• Full dash distance is derived from dash speed × full dash duration; no independent distance setting is required.
• Rear distance is derived from the same dash speed multiplied by the reduced rear duration.
• At the default multiplier, rear duration and distance are 60% of full duration and distance.
• Dashing never rotates the player or overrides current facing authority.
• Dash uses collision-aware movement and cannot teleport or pass through Walls, Vault, barriers, or other solids.
• A blocked dash continues its state and i-frame timers for their configured durations while displacement is clamped.
• Cooldown begins on successful activation and is inspector-tunable.
• Invulnerability duration is independently inspector-tunable and does not scale with full/rear duration or the rear multiplier.
• Starting dash cancels active attack and clears held attack input.
• Dash is rejected during guard, parry, defense recovery, and an existing dash.
• Attack, defense, repair, potion use, and additional dash requests are rejected while dashing.
• Dash deals no damage and preserves existing player/enemy collision behavior except for minimal dash compatibility.
• No generalized weight or enemy-displacement system is introduced.
• Dash cannot chain or become stuck, and normal movement resumes cleanly after completion.

Testing / Validation

Automated

EditMode

• Direction classification across forward, side, diagonal, and broad rear-hemisphere inputs.
• Neutral backward fallback from current facing.
• Cardinal/diagonal normalization.
• Same-speed invariant across all directional classifications.
• Full duration versus reduced rear duration.
• Default 0.60 rear multiplier.
• Full and rear distance derivation from speed and selected duration.
• Dash lifecycle, cooldown start/readiness, rejected-state behavior, and no buffering/chaining.
• Independent invulnerability timing, including i-frames outlasting rear movement.
• Mobile release-threshold policy, including outer release, inward-before-release rejection, and no historical peak arming.
• Inspector/default tuning ownership and the absence of independently authored distance or weight/displacement configuration.

PlayMode

• Desktop and gamepad movement integration.
• Forward and rear dashes visibly moving at the same speed.
• Rear dash ending sooner and traveling less distance than a full dash.
• Damage immunity following configured i-frame duration rather than full or rear movement duration.
• Player movement through the existing collision-aware path.
• Wall, Barrier, and Vault collision, sliding where supported, and blocked-dash recovery.
• Active attack cancellation and held-fire clearing.
• Defense-state rejection and action restrictions during dash.
• Mobile virtual-gamepad release path.
• Existing player/enemy collision behavior and zero dash damage.
• Clean return to normal movement without stale state.

Manual — MainPrototype

• Dash forward, left, right, diagonally, backward, back-left, and back-right.
• Verify every direction uses the same movement speed while rear directions end sooner and travel less distance.
• Verify neutral Left Ctrl performs the straight-back dodge.
• Verify backward dodge does not rotate or otherwise change player facing.
• Verify L3 movement-direction and neutral backward behavior.
• Verify mobile outer-threshold release dashes, while inward-before-release does not.
• Dash into representative Walls, barriers, and Vault geometry; verify clamping, supported sliding, continued state timing, and clean recovery.
• Verify configured i-frames can remain active after a shorter rear dodge finishes.
• Verify existing player/enemy collision behavior is preserved and dash deals no damage.
• Evaluate speed, cooldown, and invulnerability feel.

Context

• Related: feat(player): movement/defense polish pass #106, fix(player): prevent sticking against barrier and vault colliders #276, feat(input): refine responsive floating mobile joysticks #287, refactor(player): split PlayerController responsibilities #112, PR feat(player): add post-aim facing grace before movement override #290
• Milestone: P6 — Prototype Content Lock