Add reserves setpoint duration parameter for storage reserve provision

[anamileva]

Summary

Adds an optional per-project opchar column, reserves_setpoint_duration_hours: the number of hours a storage project must be able to sustain its new setpoint if its reserves are called. It replaces the hardcoded timepoint duration on the reserves side of the stor headroom/footroom energy constraints and the gen_var_stor_hyb headroom energy constraint (resolving the first TODO in stor.py). When the column is not specified, the timepoint duration is used, so existing scenarios are unchanged. The net charge/discharge energy on the right-hand side still uses the timepoint duration; the second TODO (deployment timing within the timepoint) is left in place.

The "not specified" fallback is a Param with no default plus a sparse membership check in the rule, so no sentinel value is needed and 0 hours remains a legal input.

Plumbing

• db_schema.sql column on inputs_project_operational_chars (appended after upward_reserves_to_soc_depletion)
• Column lists in gridpath/project/operations/__init__.py (inputs SQL, projects.tab writer, validation) and get_optype_inputs_from_db
• opchar_param_requirements.csv row (optional for stor and gen_var_stor_hyb)
• Data Toolkit opchar generator (eia860_to_project_opchar_input_csvs.py)
• All example opchar CSVs widened; regenerated example projects.tab files and the opchar-matrix graphics

Testing

• Param assertions added to test_stor.py and test_gen_var_stor_hyb.py (fixture projects.tab gained the column)
• New example test_w_storage_w_reserves_setpoint_duration (opchar subscenario 50: Battery gets a 4-hour requirement on hourly timepoints). Both energy constraints bind; objective -280,939,051.47 vs the unchanged base test_w_storage at -237,985,313.80
• Full parallel suite passes with zero warnings; Sphinx build is warning-free