feat(ossie/ai): ontology endpoint + describe_ossie_ontology MCP tool (#1410)

[buggtb]

Exposes the OSI ontology block through the AI Query API + the MCP
surface. Consumes the OntologyEntry / OntologyConcept /
OntologyRelationship / OntologyRole DTOs published from
bi.saiku.ossie:ossie-core:0.1.0-SNAPSHOT (spiculedata/ossie#5).

What's new

REST endpoint

GET /rest/saiku/api/ai/ossie/ontology/{connection}/{model}

Returns:

• {"connection": "...", "model": "...", "ontology": [OntologyEntry]}
• Empty list when the underlying document has no ontology block
• Same validation shape as /schema — unknown connection returns
  VALIDATION_ERROR with candidate list

MCP tool

• describe_ossie_ontology, same operand schema as describe_ossie_model
  (connection + model). Wraps the REST endpoint via
  AiOssieResource.getOntology.
• Only advertised in tools/list when AiOssieResource is wired
  (matches existing Ossie-tool gating pattern).

OssieDiscoverService

• New public getOntology(connectionName) returning List
• Refactored: extracted a package-private readDocument helper so
  getModel + getOntology share connection-validation + YAML-read code
  paths. Zero behavioural change on getModel.

Tests

• McpResourceTest: +2 cases (ontology tool advertised on tools/list
  when Ossie is wired, describe_ossie_ontology dispatches to
  getOntology on the resource). 14/14 total.
• Full saiku-service + saiku-web reactor: green.

Docs

docs/AI-OSSIE-API.md gains a new "Step 4b — inspect the ontology
block" section between validation and preview. Table of MCP tools
updated to 6.

Closes saiku#1410. Ontology-block DTOs are pure passthrough; consumers
that want to reason over the graph (subsumption, transitive closure,
concept-based navigation) build on top.