Use WPILib tunables for dashboard-adjusted values

[nlaverdure]

Goal

Use the WPILib 2027 tunables API (org.wpilib.tunable, in the tunables-java alpha-7 jar) for values that we change at runtime from a dashboard.

Candidates in the current code:

• The hand-made NT trigger topics. Drive publishes and subscribes Triggers/Align Encoders. RobotStats does the same for Triggers/Clear Robot Stats. Each one uses a publisher, a subscriber, a Trigger, and a manual reset to false.
• Hard-coded gains in DriveCommands (ANGLE_KP, ANGLE_KD, ANGLE_MAX_VELOCITY, ANGLE_MAX_ACCELERATION) and the trajectory PID gains in Drive (8.01).

Relevant API, checked with javap: Tunables.addDouble(name, default), Tunables.addBoolean(...), Tunables.publishDouble(name, getter, setter). TunableDouble implements DoubleSupplier. wpilibj includes NetworkTablesTunableBackend.

Caveats

• AdvantageKit replay will not match unless we log the values. A tunable reads from NetworkTables, which AdvantageKit does not record as an input. In replay, the code sees the default value, not the value that was set during the match. Every tunable must go through Logger.processInputs, or we should use AdvantageKit's LoggedNetworkNumber / LoggedNetworkBoolean instead. Decide this first. If we need a wrapper for every value anyway, LoggedNetwork* may be simpler than tunables.
• Do not read tunables in constructors. Subsystem constructors run at the earliest boot point, and early NT/Preferences reads have caused problems before. Read on the first periodic().
• Tuned gains must go back into code. A value tuned on the dashboard is lost on reboot unless someone copies it into the source. Add a step to the tuning procedure, or log the final values clearly.
• Low priority. Neither candidate is a correctness problem today. Re-implement Choreo auto plumbing on main-2027-alpha7 #30 is closed, so nothing blocks this. The runtime flags in OpMode variants in place of feature flags #41 need the same replay decision.