Integrate ENERO Foundry ontologies into Semantic-SQL

Nobody has claimed this yet.

## Summary
Add first-class support for ENERO Foundry ontologies in Semantic-SQL so they can be built and downloaded the same way we handle other non-OBO ontologies.

The ENERO Foundry is positioning itself as a coordination layer for interoperable energy-domain ontologies, with early ontologies including OEO, CEPO, MENO, MUNO, OTO, and CHIO. Semantic-SQL already has a partial `oeo` entry in `src/semsql/builder/registry/ontologies.yaml`, but the broader ENERO set is not yet modeled here in a consistent way.

## Why
- Energy ontologies are increasingly relevant for FAIR research data workflows.
- ENERO is explicitly trying to make these ontologies interoperable, which aligns well with SemSQL's SQL view layer over OWL/RDF.
- The repo already supports a curated registry of non-OBO ontologies, so ENERO onboarding fits the existing architecture.

## Proposed scope
- Audit candidate ENERO ontologies for stable release URLs, serialization, imports, and licensing.
- Decide which ontologies should be added to `src/semsql/builder/registry/ontologies.yaml`.
- Add registry entries, `prefixmap`s, and any necessary `build_command` overrides.
- Validate that each selected ontology can be turned into a working SemSQL SQLite build.
- Add focused tests or documented smoke-test commands for the new entries.
- Update user-facing docs so the new ontology IDs are discoverable.

## Candidate ontologies
- `oeo` (already present, likely needs validation/refresh)
- `cepo`
- `meno`
- `muno`
- `oto`
- `chio`

## Open questions
- Which ENERO ontologies publish stable machine-readable release artifacts today?
- Do any require non-default preprocessing before `rdftab` / `relation-graph`?
- Should we stage this as `oeo` hardening first, then add the rest incrementally?
- Are there any energy-adjacent artifacts we should explicitly exclude because they are not OWL reference ontologies in the SemSQL sense?

## Acceptance criteria
- At least one additional ENERO ontology beyond `oeo` is integrated end-to-end in the registry.
- The `oeo` entry is verified or corrected against the current upstream release layout.
- New entries are documented and reproducible from a clean checkout.

Start with src/semsql/builder/registry/ontologies.yaml, especially the existing oeo entry, and audit the candidate ENERO ontologies for release URLs, serialization, imports, and licensing. Use rdftab and relation-graph to validate selected entries from a clean checkout, then check that at least one ontology beyond oeo builds successfully and that the new IDs are documented.

Written by the indexing model from the issue text.