Add ogc.osc.prov-processing-step: PROV profile for a single geospatial processing step

[nsnarayanam]

D104 (Aganitha) contribution toward Activities 1 and 2. Supersedes #14, which was built from an earlier branch.

A profile of ogc.ogc-utils.prov constrained to a single geospatial processing step. Adds a required processType property linking the step to a registered process type, the link PROV-O and OGC API - Processes Part 5 (26-038) do not themselves provide, and the point where the profile-plus-register pattern closes.

Nine worked examples, all validating (9/9), profiled against a drought intelligence workflow we run in production over Telangana.

On the self-assembly point raised on the 12 Aug call: the examples form a single connected provenance graph with ten resolving links. From drought-projection a consumer can walk back through inference to the fitted model and CDSI, then to VCI and SMDI, and finally to ingest, terminating at real external inputs (the source archive, the classification scheme, the fold partition, the normalisation references). Two terminal outputs remain, the projection and the validation report.

Writing the chain up surfaced a genuine gap: CDSI consumed an SMDI entity that no recorded activity produced, so walking backwards hit a dead end. That step is now included, which is itself a small argument for chaining as a validation technique rather than only a demonstration.

Two examples cover machine learning: training is expressed as an ordinary prov:Activity whose generated entity is a fitted model, and inference then consumes that same entity as an input. Given the MLM extension has come up for the register, that round trip may be worth the group's attention.

Design question rather than a settled call: processType is bound to dct:type so the value resolves as a governed concept rather than a plain string, following the steer not to mint terms where existing ones will do. A dedicated ospd: property would be more precise. Worth deciding once rather than per block, particularly given the tier model's constraint on minting outside an allotted namespace.

parameters is deliberately left unbound in the context, pending the open question on whether process types are registered coarsely or as parameterised subtypes.

[nsnarayanam]

Superseded by #15 — adds the SMDI step and the chaining demonstration.