Instance generation infers IRI type from a string prefix instead of the schema #99

Raised from review of #95.

When generating the *_instances.py files, whether a string property value is emitted as IRI("…") or as a plain "…" string is decided by a heuristic — the value starting with http — in two places that must stay in sync:

• pipeline/src/instances_template.py.txt: {% if value.startswith('http') and key != 'id' %}…IRI("{{value}}")…
• pipeline/utils.py::_instance_needs_iri, which predicts the above to decide whether to add from openminds.base import IRI.

This is type inference from a value, not from the schema. It can misfire: a genuinely string-typed property whose value happens to start with http (e.g. a DOI string https://doi.org/… on a string field) would be wrongly wrapped in IRI(...), and conversely an IRI-typed value that doesn't start with http would be emitted as a bare string.

Proposed fix

Drive the decision from the property's declared schema type (type == "IRI") rather than from the value. The builder already knows each property's type in translate(); thread a per-class set of IRI-typed property names into instance-file generation and use it in both the template and _instance_needs_iri.

Note

This heuristic predates #95 (the previous module_template used the same startswith('http') test); #95 only carried it forward. Low urgency, but worth fixing properly since the schema type is authoritative.