Pin the SQL surface curate() accepts and document the one-SELECT rule

[RinZ27]

Summary

Pins which SQL forms _reject_non_single_select accepts and refuses, and documents the one-SELECT rule in docs/CATALOG.md.

Why

After #271 landed the guard, the accepted SQL surface changed in both directions but nothing wrote it down. PIVOT is now refused (DuckDB rewrites it to [CREATE, SELECT], so the count check catches it — arguably correct rather than merely strict). DESCRIBE SELECT ... and SUMMARIZE SELECT ... moved the other way: both report as SELECT and now pass the guard, where previously they were syntax errors inside the old COPY (...) wrapper.

Without a pin, someone will eventually "relax" the count check to let PIVOT through without realising the CREATE it admits is the thing the guard exists to stop. And DESCRIBE/SUMMARIZE working by accident means nothing would notice if a future DuckDB reclassified them.

Decision on DESCRIBE and SUMMARIZE: both are accepted incidentally. The test records that fact and names them as not a promised surface, matching what the docs paragraph now says. If a future DuckDB version reclassifies either one, the test goes red and forces a deliberate choice rather than silent breakage.

Validation

$ uv run pytest tests/test_catalog_curation.py::test_reject_non_single_select_sql_surface -v
11 passed in 0.78s

$ uv run pytest tests/test_catalog_curation.py -q
80 passed, 5 errors in 2.98s
# (errors are pre-existing ffmpeg._binary — no ffmpeg on this machine)

$ uv run ruff check --fix && uv run ruff format && uv run ty check
All checks passed

Checklist

• I added or updated outcome-focused tests for changed business logic.
• I updated documentation for changed behavior, flags, formats, or requirements.
• I ran uv run ruff check --fix, uv run ruff format, and uv run ty check.
• I ran the relevant pytest suite.
• I did not add recordings, generated media, credentials, private URLs, or runtime artifacts.
• I preserved stored-data compatibility or documented an explicit version change.

Closes #279

[github-actions]

👋 Hi @RinZ27 — thank you so much for your first contribution to HFlow!

A maintainer will review your pull request as soon as possible. In the meantime:

• ⭐ Star the repo: https://github.com/Hebbian-Robotics/hflow
• 💬 Join our Discord: https://discord.gg/vacepQvjmg
• 📖 Check CONTRIBUTING.md for the validation commands CI will run
• 📣 Share the project with your network

💡 Tip: one open pull request per contributor at a time. Issues with an assignee are taken; everything else is fair game.

We are excited to have you here and appreciate your help making the project better! 🙌

[kstonekuan]

Sorry, closing this one. #279 is assigned and #285 has been open on it since 10:20, so first-PR-wins applies. Timing, nothing about your work.

For next time: comment on an issue before you start and I'll assign it, and check whether it already has an assignee or a linked PR. An issue with an assignee is taken, everything else is fair game.

The starter pool is picked clean this morning, more go up regularly. If you'd rather not wait, the most useful thing anyone can do here is run HFlow against a real corpus, Egocentric-10K or Egocentric-100K on HF, and report what breaks, what's slow, what's awkward. See #287.

https://github.com/Hebbian-Robotics/hflow/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22