Resolve HF Spaces gradio version conflict

HF Spaces builds its runtime based on README.md's sdk_version
frontmatter field and raises a version-conflict build error when
requirements.txt also lists gradio — sdk_version always wins on HF's
side and the conflict surfaces before pip is even invoked.

Two changes:
- README.md: sdk_version 4.44.1 -> 4.31.5 to match our intent
(4.44.1 ships gradio_client 1.3.0 with the jinja cache +
additionalProperties schema regressions we hit earlier).
- requirements.txt: drop the `gradio==4.31.5` line entirely so HF
only sees the sdk_version declaration. Kept the huggingface_hub
upper bound because gradio 4.x still imports HfFolder, which was
removed in huggingface_hub 1.0.

Local runs are unaffected: gradio 4.31.5 is still resolvable from
other installers.

README.md

@@ -4,7 +4,7 @@ emoji: 🔧
 colorFrom: blue
 colorTo: purple
 sdk: gradio
-sdk_version: 4.44.1
+sdk_version: 4.31.5
 python_version: "3.10"
 app_file: app.py
 pinned: false

requirements.txt

@@ -3,12 +3,13 @@ pydantic>=2.0
 networkx>=3.0
 Pillow>=10.0
 tqdm>=4.65
-# Pin to 4.31.5: 4.44.1 ships gradio_client 1.3.0 which has two bugs that
-# trip this app on HF Spaces — (1) json_schema_to_python_type crashes on
-# bool additionalProperties values emitted by FileData/PlotData, and (2) a
-# jinja2 template cache issue raises "TypeError: unhashable type: 'dict'".
-# 4.31.5 ships gradio_client 0.16.4 which predates both.
-gradio==4.31.5
+# gradio is intentionally NOT listed here: HF Spaces auto-installs the
+# version declared in README.md's `sdk_version` frontmatter field, and
+# listing it again in requirements.txt causes a version-conflict build
+# error (HF forces sdk_version to win). Bump sdk_version in README.md
+# to upgrade. See the repo README for the full rationale on why we pin
+# to gradio 4.31.5 (gradio_client 1.3.0 regressions in 4.44.1).
+
 # gradio 4.x imports HfFolder which was removed in huggingface_hub 1.0
 huggingface_hub>=0.26,<1.0
 matplotlib>=3.7