feat(adr/007-default-runtime.md): add future work section discussing WASM potential

Add a new section to the ADR document outlining potential future work with WebAssembly (WASM) as an alternative runtime, comparing it to Java's bytecode and JVM model, highlighting potential benefits in observability, heap allocation, and garbage collection. Note current maturity limitations compared to our target customer base.

adr/007-default-runtime.md

@@ -66,3 +66,14 @@ We selected **k3s as the default runtime** for managed workloads on Linux platfo
 - **Relying on User-Provided Runtime:**  This would require users to install and configure their own runtime environment, which goes against our "zero setup" goal.  Increases support burden and leads to inconsistent environments.
 - **Virtual Machines (VMs):** Using VMs would provide isolation, but would be much more resource-intensive and slower to start than container-based solutions.
 
+## Future work
+
+There is a hype cycle around WASM that holds some ground : WASM to replace containers makes sense in many ways.
+
+To me, it feels just like Java with bytecode. If you can compile to bytecode, all you need to run your program is a JVM. Now, as long as you can compile to WASM, you can run your program on any WASM runtime.
+
+This feels like a sensible iteration over both managing containers, that are just bundling a bunch of libraries to make sure your program has everything it needs. This brings major benefits that used to come with the JVM such as observability into heap allocation, garbage collection, etc.
+
+The benefits won't be the exact same but it is reasonable to consider that this simplification and unification of runtime from containers to WASM will bring very significant improvements to the entire software delivery lifecycle.
+
+Down the road, it will be interesting to consider WASM, but the maturity versus our target customer base is not there yet.