dmactive does not reset abstract-command and SBA state #197

Description

Writing dmcontrol.dmactive = 0 resets the CSR state in src/dm_csrs.sv, but it does not consistently reset the other Debug Module engines. In particular, the abstract-command FSM in src/dm_mem.sv can remain in Go or CmdExecuting, and the SBA FSM in src/dm_sba.sv ignores its existing dmactive_i input. A stale Go indication, abstractcs.busy, or system-bus request can therefore survive Debug Module deactivation and reappear after reactivation.

All Debug Module-owned state and externally visible requests should take their reset values while dmactive is zero. The implementation should define and apply one reset policy to the CSR block, abstract-command FSM, debug-memory flags, resume acknowledgements, and SBA FSM.

Relevant code:

• src/dm_csrs.sv: dmactive reset handling
• src/dm_mem.sv: abstract-command FSM and Go flag generation
• src/dm_sba.sv: p_fsm; dmactive_i is present but not used to reset or quiesce the FSM

Issue #65 previously discussed part of this reset behavior and requested a separate issue, but it did not track the complete Debug Module reset policy.

Specification references in RISC-V External Debug Support 0.13.2:

• Section 3.2, Reset Control, document p. 8 (PDF p. 18): Debug Module state and registers are reset at power-up and while dmcontrol.dmactive is zero, while ndmreset excludes the Debug Module
• Section 3.12.2, Debug Module Control, dmactive, document p. 25 (PDF p. 35): when dmactive is zero, the module's state must take its reset values; pulsing it low returns the Debug Module to a known state

This issue was found via Codex review.