fix: handle negative values in dehumanize()

[jermaine-hicks]

Problem

dehumanize() silently ignores a leading minus sign on numeric values. "in -1 hours" is parsed identically to "in 1 hours" and shifts the time forward instead of producing a correct or clearly-invalid result.

>>> base = arrow.Arrow(2025, 1, 1, 12, 0, 0)
>>> base.dehumanize("in 1 hours")
<Arrow [2025-01-01T13:00:00+00:00]>
>>> base.dehumanize("in -1 hours")   # expected error or backward shift
<Arrow [2025-01-01T13:00:00+00:00]>  # identical to "in 1 hours"

Fixes #1278.

Root cause

The numeric value is extracted with a digit-only regex (\d+), and the unit search template substitutes \d+ for {0}. Neither captures a sign, so the - is dropped. Direction is taken solely from the past/future templates ("... ago" / "in ..."), and the magnitude is always treated as positive.

Fix

humanize() only ever emits positive magnitudes and encodes direction through the past/future templates, so a negative number is malformed input — not a second, conflicting direction signal. This aligns with how dehumanize() already handles every other malformed-input case (scrambled input, missing relative unit, etc.): it raises ValueError.

The fix detects a - immediately preceding the matched digits in the original input string and raises a clear ValueError instead of silently dropping it. Positive inputs are completely unaffected.

Tests

Adds TestArrowDehumanize::test_negative_values, covering negative values in both future ("in -1 hours") and past ("-3 hours ago") forms across several units, plus a sanity check that the positive forms still work. Full suite: 1902 passed, 1 skipped; arrow/arrow.py coverage 100%.