Handle mapped form of neura.add in interpreter

[TimJZ]

Background

The Neura spatial mapper (`--map-to-accelerator`) transforms pre-mapping IR into a tile-assigned, physically-routed form. As part of this transformation, compile-time constant operands are folded from SSA values into operation attributes. Specifically, an instruction like:

```mlir
%res = "neura.add"(%lhs, %const_1) : (!neura.data<i64, i1>, !neura.data<i64, i1>) -> !neura.data<i64, i1>
```

becomes:

```mlir
%res = "neura.add"(%lhs) {rhs_value = 1 : i64} : (!neura.data<i64, i1>) -> !neura.data<i64, i1>
```

This single-SSA-operand form is the intended post-mapping representation — the `$rhs` field in `Neura_AddOp` is defined as `Optional` in `NeuraOps.td` precisely to support it. However, `handleAddOp` in the interpreter unconditionally rejected any op with fewer than two SSA operands, making it impossible to interpret any fully mapped IR that contains `neura.add`.

This was observed when running `neura-interpreter` on the ReLU e2e mapped IR (`test/e2e/relu/Output/relu_kernel.mlir.tmp-mapping.mlir`), where the loop index increment `i + 1` maps to:

```mlir
%23 = "neura.add"(%22) {rhs_value = 1 : i64} : (!neura.data<i64, i1>) -> !neura.data<i64, i1>
```

PR Summary

Interpreter

• Extend `handleAddOp` to handle the single-operand mapped form: detect `numOperands == 1`, read the constant from the `rhs_value` `IntegerAttr`, and synthesize a `PredicatedData` with `predicate = true` (compile-time constants are always valid)
• Retain the existing two-operand path unchanged so pre-mapping IR continues to work
• Add a zero-operand error path with a clear diagnostic

Tests

• Add Test 5 to `test/neura/interpreter/basic_operation/add.mlir`: uses `neura.grant_once` to produce a typed `!neura.data<i64, i1>` value, then applies `neura.add` with `rhs_value = 5` and verifies the output is `15.000000`
• All existing tests (Tests 1–4, two-operand pre-mapping form) continue to pass

[tancheng]

What are we actually targeting? I mean should we target a kernel like: https://github.com/coredac/neura/blob/main/test/e2e/fir/fir_kernel.mlir? and support all the missing ops required by that kernel?

[itemkelvin]

Good job. This issue definitely exists in similar ops as well.

[tancheng]

Good job. This issue definitely exists in similar ops as well.

Thanks for chiming in @itemkelvin. @TimJZ Can you please share your slides with @itemkelvin so that you two can split the workloads? One can focus on CFG validation and the other one can focus on DFG validation.

@ShangkunLi can you invite both of them into your discord space, so we can share stuff? You can create a neura-interpreter space/community/group.

[ShangkunLi]

Good job. This issue definitely exists in similar ops as well.

Thanks for chiming in @itemkelvin. @TimJZ Can you please share your slides with @itemkelvin so that you two can split the workloads? One can focus on CFG validation and the other one can focus on DFG validation.

@ShangkunLi can you invite both of them into your discord space, so we can share stuff? You can create a neura-interpreter space/community/group.

Hi~ @itemkelvin @TimJZ, here is the Discord space link https://discord.gg/UfaUCT3AyQ, plz feel free to discuss in it.

[TimJZ]

Good job. This issue definitely exists in similar ops as well.

Thanks for chiming in @itemkelvin. @TimJZ Can you please share your slides with @itemkelvin so that you two can split the workloads? One can focus on CFG validation and the other one can focus on DFG validation.

@ShangkunLi can you invite both of them into your discord space, so we can share stuff? You can create a neura-interpreter space/community/group.

Yeah sure! @itemkelvin Could you share an email address with me? I have some slides on Google Slides, and we can discuss offline on how to split the workload. Thanks!