chore: improve resource discovery and reference handling for new sections

[frodehk]

Summary

Small fixes and improvements to YAML resource discovery, reference handling, and mapper robustness. Discovered while running the migration tooling against existing models, but valuable independently.

Changes

• yaml_reference_service.py: register FLUID_MODELS entries so they are resolvable through the reference service.
• pyyaml_yaml_model.py:
  • structure-agnostic helper to find FILE references nested inside the new YAML sections (PROCESS_UNITS, PROCESS_SYSTEMS)
  • auto-detect is_single_speed from chart resource headers
  • declare fluid_models as an abstract property on YamlValidator
• process_simulation_mapper.py: defensive None-handling in _map_conditions.

No behavioral change for existing models — these only enable correct handling of newer YAML constructs and improve type safety.

Type of Work

• Patch: X.Y.Z+1. NEGLIGIBLE visible changes, does not change input or output - OR changes behaviour. Use chore:, refactor: etc
• Minor: X.Y+1.Z. Minor changes, might ADD new input (YAML), or other backwards-compatible changes. Use feat:, fix:
• Major: X+1.Y.Z. Major and most likely BREAKING changes, wo. backwards compatibility, or removing temporary backwards compatibility functionality. Use ! or BREAKING:.

See here (internal): https://github.com/equinor/ecalc-internal/discussions/1044

Have you remembered and considered?

• IF FEAT: I have remembered to update documentation
• IF FIX OR FEAT: I have remembered to update manual changelog (docs/drafts/next.draft.md)
• IF BREAKING: I have remembered to update migration guide (docs/docs/migration_guides/)
• IF BREAKING: I have committed with BREAKING: in footer or ! in header
• I have added tests (if not, comment why)
• I have used conventional commits syntax (if you squash, make sure that conventional commit is used)
• I have included the Github issue nr in the footer!

What is this PR all about?

What else did you consider?

Between the lines?

[jsolaas]

Also replace facility and model 'search' above? Search everything except TIME_SERIES? Or do we need to separate TIME_SERIES and FACILITY when looking at resources?

[frodehk]

Good point.

I kept the new search to the new sections (PROCESS_UNITS, PROCESS_SYSTEMS) on purpose. I think replacing the existing facility/model search will be a refactor that may require some test coverage - better to keep in a separate PR? I think TIME_SERIES probably needs to stay separate, since they map to a different resource type.