Fix two bugs found during test-matrix expansion

[chazlarson]

Summary

Two bugs surfaced while writing the test-matrix expansion PR (#1330). Both are fixed here with regression tests.

---

Bug 1 — database.reset_data() crashes on a fresh SQLite file

What happened

reset_data() was the only function in modules/database.py that issued a DELETE without first running CREATE TABLE IF NOT EXISTS. On a fresh config directory (clean install, CI, isolated test fixture) this raises:

sqlite3.OperationalError: no such table: section_data

Every other helper in the module (save_section_data, retrieve_section_data, retrieve_all_section_data, etc.) follows the pattern:

cursor.execute(persisted_section_table_create())  # CREATE TABLE IF NOT EXISTS …
cursor.execute(sql, ...)

reset_data skipped the first line.

Fix

# modules/database.py  reset_data()
cursor.execute(persisted_section_table_create())  # ← added
sql = "DELETE from section_data where name == ?"
...

One line; matches the established pattern.

---

Bug 2 — validate_github route crashes when the GitHub token is invalid

What happened

validate_github_server() in modules/validations.py returns either a plain Flask response or a (jsonify(payload), 400) tuple depending on the HTTP outcome:

# modules/validations.py
if response.status_code == 200:
    return jsonify({"valid": True, ...})
else:
    return jsonify({"valid": False, ...}), 400   # ← tuple

The validate_github route called result.get_json() directly without unpacking the tuple first:

# blueprints/validation_routes.py  (before fix)
result = validations.validate_github_server(data)
if result.get_json().get("valid"):   # ← AttributeError when result is a tuple
    ...

This crashes with AttributeError: 'tuple' object has no attribute 'get_json' every time a GitHub token is rejected.

Root cause: inconsistent route pattern

The validate_radarr and validate_sonarr routes already handled both forms:

result = validations.validate_radarr_server(data)
status_code = 200
if isinstance(result, tuple):
    result, status_code = result
if result.get_json().get("valid"):
    ...

The other five routes (omdb, github, tmdb, mdblist, notifiarr) did not.

Fix

A new module-level helper normalises both forms:

def _unpack_validation_result(result):
    """Normalise a validator return value into (flask_response, status_code|None)."""
    if isinstance(result, tuple):
        return result[0], int(result[1])
    return result, None  # caller uses status_code or 400

All seven routes now use it:

result, status_code = _unpack_validation_result(validations.validate_xxx_server(data))
if result.get_json().get("valid"):
    return jsonify(result.get_json())
return jsonify(result.get_json()), status_code or 400

The None sentinel ensures None or 400 = 400 — the correct fallback for plain-response errors — while an explicit 400 from a tuple passes straight through.

---

Tests — tests/test_bug_fixes.py (+16 tests)

Bug 1 (4 tests)

• reset_data() does not crash on a totally fresh SQLite file (no section arg)
• reset_data(name, section=...) does not crash on a fresh SQLite file
• reset_data() removes existing rows
• Section-scoped reset_data(name, section=X) leaves other sections untouched

Bug 2 (6 tests)

• validate_github returns 400 (not 500) when validator returns a tuple ← the crash
• validate_github returns 200 on success
• validate_github returns 400 on plain-response error
• _unpack_validation_result handles plain response (returns None sentinel)
• _unpack_validation_result handles tuple
• _unpack_validation_result coerces status code to int

Hardening (6 tests — parametrized)

• All 7 routes (radarr, sonarr, omdb, github, tmdb, mdblist, notifiarr) survive a tuple return from their validator and produce 400

---

CI

• 817 tests pass (801 existing + 16 new), zero regressions
• ruff check clean on all 3 changed files