flepimop2-op_system: track flepimop2 main (ModuleBase consolidation, .patch, patch CLI); bump pin and release 0.3.0

[jc-macdonald]

Summary

The flepimop2-op_system connector (in this repo at flepimop2-op_system/) needs to be brought up to date with the recent module-architecture consolidation on flepimop2 main. The connector currently works against the new base classes by accident — it should explicitly adopt the documented patterns and bump its minimum flepimop2 pin.

Upstream changes that affect us

On GMU-CSDS/flepimop2 main (HEAD ~aaa0d66):

1. Remove non-pydantic approach to modules (commit 83ead31) — renames ModuleABC → ModuleBase, makes it BaseModel-based, and re-bases SystemABC(ModuleBase, module_namespace="system") on it. Concrete modules now declare their identity via class-kwargs: class Foo(SystemABC, module="<dotted.name>").
2. Add ModuleBase.patch (commit 8593db2) — modules and ConfigurationModel gain a .patch(...) method for in-place pydantic-aware overrides.
3. Add flepimop2 patch CLI (commit aaa0d66) — exposes the above via the CLI.
4. The docs/development/pydantic-for-modelers.md doc now prescribes the canonical pattern: subclass declares module: Literal["<dotted.name>"] = "<dotted.name>" (or relies on the module= class-kwarg shortcut) and model_config = ConfigDict(extra="forbid").

Current connector state

flepimop2-op_system/src/flepimop2_op_system/system.py:

class OpSystemSystem(SystemABC, module="flepimop2.system.op_system"):
    spec: Mapping[str, Any]
    ...
    def model_post_init(self, __context):
        self._compiled = compile_spec(self.spec)

• Imports and class definition resolve under the new ModuleBase; issubclass(OpSystemSystem, BaseModel) is True at runtime.
• pyproject.toml declares version = "0.2.0" but the installed editable metadata still reports 0.1.2 — a release/tag was missed.
• Dependency pin is flepimop2>=0.2.0. The new ModuleBase work landed in flepimop2>=0.3.0.dev0; older versions will fail at class creation.
• The connector does not yet expose / test ModuleBase.patch semantics, and there is no integration smoke that exercises the new CLI surface.

Tasks

• Bump flepimop2-op_system to 0.3.0 (or 0.2.1 if you want to keep the connector minor in lockstep with flepimop2's minor), tag, and refresh the editable install metadata.

• Change the flepimop2 dependency pin to >=0.3.0.dev0 (or whatever the first release containing 83ead31 is).

• Adopt the documented Literal pattern explicitly:

  class OpSystemSystem(SystemABC):
      module: Literal["flepimop2.system.op_system"] = "flepimop2.system.op_system"
      model_config = ConfigDict(extra="forbid")
      spec: Mapping[str, Any]
      ...

  (Keeping the module="..." class-kwarg form is also legal — pick one and document it.)

• Add a smoke test that constructs an OpSystemSystem from a tiny spec and calls .patch(spec=...), verifying re-compilation behavior.

• Add a regression test that runs flepimop2 patch ... against a YAML config containing an op_system system: block.

• README/CHANGELOG note for the supported flepimop2 floor.

Repro of the pin issue

$ python -c "import importlib.metadata as m; print(m.version('flepimop2-op_system'), m.version('flepimop2'))"
0.1.2 0.3.0.dev0

Refs

• GMU-CSDS/flepimop2 commit 83ead31 (ModuleBase consolidation)
• GMU-CSDS/flepimop2 commit 8593db2 (ModuleBase.patch)
• GMU-CSDS/flepimop2 commit aaa0d66 (flepimop2 patch CLI)
• ACCIDDA/COVID19_USA configs SMH_R19_op_system*.yml are the primary downstream consumer and a good integration target.

[jc-macdonald]

The requested 0.3 catch-up is superseded: both op_system and its provider are now on the 0.4 release line, and the current connector already uses the ModuleBase API. PR #142 was closed because it would downgrade current metadata. The remaining stale module-version constant is tracked separately in #231.