Improve Emissions handling consistency

[boulderdaze]

These three tasks are related to the code in src/validate.cpp.

• Build assembles species/phases/reactions/aerosol, but emissions is parsed separately. To unify mechanism construction, move ParseEmissionsSection(...) into Build so species, phases, reactions, aerosol, and emissions are all assembled in one place.

• Separate emissions validation: Validate(const Mechanism&) currently validates gas and aerosol, with emissions handled inside ValidateGasModel. Since emissions are optional, consider introducing a dedicated ValidateEmissionsModel function.

• Verify whether emissions are only semantically validated during parsing and not for in-code mechanisms. If so, add equivalent validation to the in-code mechanism validation path.

src/v1/parser.cpp

  std::expected<Mechanism, Errors> Parser::ValidateAndBuild(const YAML::Node& object)
  {
    try
    {
      Errors errors = CheckSchema(object);

      if (errors.empty()) {...}

      if (!errors.empty()){...}

      Mechanism mechanism = Build(object);

      Errors aerosol_errors = ValidateAerosolModel(mechanism);
      if (!aerosol_errors.empty())
      {
        AppendFilePath(config_path_, aerosol_errors);
        return std::unexpected(std::move(aerosol_errors));
      }

      /// 
      /// Asymmetry: Build assembles species/phases/reactions/aerosol, but emissions is parsed separately after.
      /// 
      if (object[std::string(keys::emissions)])
      {
        mechanism.emissions = ParseEmissionsSection(object[std::string(keys::emissions)]);
      }
      return mechanism;
    }
    catch (const std::exception& e){...}
  }

  Mechanism Parser::Build(const YAML::Node& object)
  {
    Mechanism mechanism;

    mechanism.version = Version(object[keys::version].as<std::string>());
    mechanism.species = ParseSpecies(object[keys::species]);
    mechanism.phases = ParsePhases(object[keys::phases]);
    
    if (object[keys::reactions])
    {
      mechanism.reactions = ParseReactions(object[keys::reactions]);
    }
    if (object[keys::aerosol_representations] && object[keys::aerosol_processes]) 
    {
      mechanism.aerosol = ParseAerosol(object, mechanism.species, mechanism.phases);
    }
    /// 
    /// Build assembles species/phases/reactions/aerosol, but emissions is parsed separately. 
    /// 
    if (object[keys::name])
    {
      mechanism.name = object[keys::name].as<std::string>();
    }

    return mechanism;
  }

[smeechncar]

Thanks for flagging these — went through the code to check each one against what's on main and what this PR does:

1. Move ParseEmissionsSection into Build() — agreed. Build() already assembles species/phases/reactions (and aerosol, per this PR), so emissions is the odd one out getting parsed separately in ValidateAndBuild. Build() already has the raw YAML node, so folding emissions in there is straightforward and keeps mechanism assembly in one place.

2. Split emissions out of ValidateGasModel — also agreed. This PR renames the old Validate() straight to ValidateGasModel, which carries over the emissions validation from Add emissions configuration schema (inventories, species maps, sources) to mechanism v1 #281 verbatim. Emissions is its own optional section, same as aerosol, so it shouldn't live inside something named for gas chemistry. A dedicated ValidateEmissionsModel would match the pattern this PR already sets with ValidateAerosolModel. Might be worth renaming ValidateGasModel at the same time so it's clear what's actually left in it.

3. In-code mechanism emissions validation — this one's already done. Validate(const Mechanism&) has validated emissions for in-code mechanisms since Add emissions configuration schema (inventories, species maps, sources) to mechanism v1 #281 (that logic is what got carried into ValidateGasModel in this PR), and it's covered by tests in test/unit/test_validate.cpp (duplicate inventory/species-map/source, unknown references, scaling factor bounds, etc). It'll move automatically once emissions validation is split out per added basic pages and one example #2, so I'd consider this checked off.

So: +1 on 1 and 2, and 3 can be closed as already satisfied.