docs(profile): describe stream-layers tier as a solid peer (figure + text + in-flight PRs)

profile/README.md

@@ -56,9 +56,19 @@ This is the platform's **portable computation** property — one query text, thr
 | [MobilityDuck](https://github.com/MobilityDB/MobilityDuck) | DuckDB extension — peer SQL layer for analytics / columnar workloads. |
 | [MobilitySpark](https://github.com/MobilityDB/MobilitySpark) | Apache Spark plugin — peer SQL layer for distributed and large-scale workloads, with MEOS-backed UDFs and DataFrame integration. |
 
-### 🌊 Stream layers (planned)
+### 🌊 Stream layers
 
-**Planned — not yet built.** The same edge-to-cloud model is planned for the streaming side of the ecosystem, each tool in its canonical role: [MobilityNebula](https://github.com/MobilityDB/MobilityNebula) ([NebulaStream](https://nebula.stream/)) on the **edge**, [MobilityKafka](https://github.com/MobilityDB/MobilityKafka) ([Apache Kafka](https://kafka.apache.org/)) as the streaming **transport backbone** in between, and [MobilityFlink](https://github.com/MobilityDB/MobilityFlink) ([Apache Flink](https://flink.apache.org/)) for **stream processing in the cloud** — reproducing the SNCB benchmark from [*MobilityNebula* (EDBT 2026)](https://docs.mobilitydb.com/pub/MobilityNebula_EDBT_2026.pdf). It is drawn as a dashed, ghosted box — same format as the other peer boxes, second in the peers row of the figure above (dashed = not yet built).
+The same edge-to-cloud model runs on the streaming side of the ecosystem, each tool in its canonical role: [MobilityNebula](https://github.com/MobilityDB/MobilityNebula) ([NebulaStream](https://nebula.stream/)) on the **edge**, [MobilityKafka](https://github.com/MobilityDB/MobilityKafka) ([Apache Kafka](https://kafka.apache.org/)) as the streaming **transport backbone** in between, and [MobilityFlink](https://github.com/MobilityDB/MobilityFlink) ([Apache Flink](https://flink.apache.org/)) for **stream processing in the cloud**. The published reference architecture is [*MobilityNebula* (EDBT 2026)](https://docs.mobilitydb.com/pub/MobilityNebula_EDBT_2026.pdf), with real railway data (SNCB) as the application demonstration. It is the second peer in the row of peer surfaces in the figure above.
+
+The parity contract matches the SQL-layer one: **the same BerlinMOD reference queries run across all three platforms in three streaming forms — continuous (always-on), windowed (tumbling / sliding / session), and snapshot (query at time T, ≡ the batch result at the same scale factor)** — with the snapshot form anchored to the batch BerlinMOD outputs in [MobilityDB-BerlinMOD](https://github.com/MobilityDB/MobilityDB-BerlinMOD). The same generator and scale-factor axis as the batch side are reused.
+
+The Flink and Kafka platforms use [JMEOS](https://github.com/MobilityDB/JMEOS); MobilityNebula calls MEOS directly through its C ABI.
+
+The streaming-form parity matrix is scaffolded across all three runtimes — [MobilityFlink#3](https://github.com/MobilityDB/MobilityFlink/pull/3), [MobilityKafka#1](https://github.com/MobilityDB/MobilityKafka/pull/1) and [MobilityNebula#15](https://github.com/MobilityDB/MobilityNebula/pull/15) — each implementing the full 27-cell BerlinMOD-Q × 3-form matrix in the runtime's native operator surface. **81 / 81 cells full, 0 partial.**
+
+On the JVM platforms the spatial-predicate surface routes through a single `MEOSBridge` class — [MobilityFlink#4](https://github.com/MobilityDB/MobilityFlink/pull/4) and [MobilityKafka#2](https://github.com/MobilityDB/MobilityKafka/pull/2) — calling MEOS' `geog_dwithin` over WGS84 geographies via [JMEOS#18](https://github.com/MobilityDB/JMEOS/pull/18)'s `utils.spatial.Haversine` and `utils.spatial.PointToSegment` wrappers when libmeos is loadable, with a pure-Java great-circle fallback for the mini-cluster local-test runs. The 27 cells × 2 platforms are MEOS-backed at every predicate AND distance site.
+
+On the NebulaStream side, three stacked PRs add the BerlinMOD-specific aggregations across the four pipeline layers (logical / physical / parser / lowering): [MobilityNebula#16](https://github.com/MobilityDB/MobilityNebula/pull/16) adds `TEMPORAL_LENGTH` (Q6), and [MobilityNebula#17](https://github.com/MobilityDB/MobilityNebula/pull/17) adds `PAIR_MEETING` (Q5) + `CROSS_DISTANCE` (Q9), all calling MEOS C directly. Together with PR#15, the MobilityNebula matrix-row is 27 / 27 full.
 
 | Repository | Engine |
 |---|---|