feat(meos): parameterize PAIR_MEETING dMeet via SQL constant fifth arg (stacks on #18)

[estebanzimanyi]

Implements the "Future PR can parameterize DMEET via a constant input to the aggregation" future-work item from PR #17 (PAIR_MEETING body, header PairMeetingAggregationPhysicalFunction.hpp).

cc @marianaGarcez — this is a maintainer-build-verification PR; my environment can't compile NebulaStream (full C++23 + vcpkg toolchain needed). Submitting the spike with explicit Serde caveat (below) for your iteration.

Surface change

PAIR_MEETING(lon, lat, ts, vehicle_id, dMeet)
                                       ^^^^^ NEW — numeric constant (metres)

The first four args remain FieldAccess (lon, lat, ts, vehicle_id); the fifth is a numeric constant pulled from the parser's constantBuilder, parsed via std::stod, and threaded through the logical → lowering → physical chain into the lower() lambda's argument list (alongside the existing vehicleMapPtr and pairsBuffer) via nautilus::val<double>.

9 files modified (across the 4 NebulaStream pipeline layers + 3 YAML scaffolds)

Layer	File	Change
Physical .hpp	nes-physical-operators/include/Aggregation/Function/Meos/PairMeetingAggregationPhysicalFunction.hpp	static constexpr DMEET_METRES → static constexpr DEFAULT_DMEET_METRES + instance double dMeetMetres field; constructor takes it
Physical .cpp	nes-physical-operators/src/Aggregation/Function/Meos/PairMeetingAggregationPhysicalFunction.cpp	Constructor body initializes dMeetMetres; lower() passes nautilus::val<double>(dMeetMetres) to the captureless lambda which uses it in geog_dwithin(ggA, ggB, dMeet, true)
Logical .hpp	nes-logical-operators/include/Operators/Windows/Aggregations/Meos/PairMeetingAggregationLogicalFunction.hpp	Constructor + create() factory take double dMeetMetres; getter getDMeetMetres()
Logical .cpp	nes-logical-operators/src/Operators/Windows/Aggregations/Meos/PairMeetingAggregationLogicalFunction.cpp	Field initialization; Registrar deserialize path uses DEFAULT_DMEET_METRES (see Serde caveat)
Parser	nes-sql-parser/src/AntlrSQLQueryPlanCreator.cpp	Both PAIR_MEETING dispatch sites (lexer-token case + funcName string-name case) — extract constant from constantBuilder, std::stod it, pass to create()
Lowering	nes-query-optimizer/src/RewriteRules/LowerToPhysical/LowerToPhysicalWindowedAggregation.cpp	pmDescriptor->getDMeetMetres() → physical constructor
YAMLs (×3)	Queries/berlinmod/q5_continuous.yaml, q5_snapshot.yaml, q5_windowed.yaml	Add , 200.0 as the explicit fifth arg; comments updated to reflect parameterization

YAML parse-validated locally (python3 -c "import yaml; yaml.safe_load(...)" on each). No C++ compile verification possible — see below.

Serde round-trip caveat (deliberately out of scope)

AggregationLogicalFunctionRegistryArguments is strongly typed to vector<FieldAccessLogicalFunction> — there is no slot for a numeric constant in the Registrar interface, and SerializableAggregationFunction (the proto) has no field for it either. As a result:

• Parser path (live query execution): FULLY parameterized. The dMeet flows from SQL → logical → lowering → physical correctly.
• Serde deserialize path: falls back to DEFAULT_DMEET_METRES (200 m, the previous hardcode). Round-trip fidelity for the dMeet value requires:
  • (a) adding a new field to SerializableAggregationFunction.proto
  • (b) extending AggregationLogicalFunctionRegistryArguments to carry the constant
  • (c) threading both through Serialize() / Register…() in the logical .cpp

This is an infrastructure change touching the Registrar interface (which every NebulaStream aggregation registers through) and the proto schema (which has its own regeneration step). Out of scope for this spike; would be a coherent follow-up if cross-process query-plan serialization for the parameterized dMeet is needed.

Mirrors CROSS_DISTANCE

CROSS_DISTANCE (also added in #17, with hardcoded VID_A=100, VID_B=200) has the exact same parameterization pattern — the only differences are: 2 constants instead of 1, integer instead of double, and the parser+lowering need to extract both. Holding for a sibling PR with the same shape.

What needs maintainer attention

1. Build verification — does this compile against the full NebulaStream + vcpkg toolchain? My environment can't run that.
2. The nautilus::val<double> passing pattern in the lambda — I extrapolated from the existing nautilus::val<size_t>(0) pattern in the same file, but I'm uncertain whether nautilus::val<double> is the correct val type for a double lambda arg or whether the lambda signature needs nautilus::val<double> parameters instead of plain double. The build will tell.
3. Default-value behavior for deserialized plans — falling back to 200 m on deserialize is preserved-behavior for the BerlinMOD scaffold, but if you'd prefer the deserialize path to throw rather than silently default, that's a one-line change in the Registrar.

Stacks on PR #18 (docs overlay) → PR #17 (PAIR_MEETING + CROSS_DISTANCE addition) → PR #16 (TEMPORAL_LENGTH) → PR #15 (scaffold).