[firtool][repl-seq-mem] `firtool --repl-seq-mem` drops `loadMemoryFromFileInline` initialization metadata from companion output

Nobody has claimed this yet.

## Summary

When a memory uses `loadMemoryFromFileInline`, running `firtool` with `--repl-seq-mem` appears to lose the memory initialization-file metadata in the companion output.

As a result, downstream external-memory generators can reconstruct the memory shape and ports, but cannot preserve the original `$readmemh(...)` initialization semantics.

## Expected behavior

If a memory is annotated with `loadMemoryFromFileInline`, then after `--repl-seq-mem` the companion output should still preserve enough information to represent the memory-file initialization.

For example, the companion metadata could include an `init_file` field or another structured representation of the memory-file annotation.

## Version

- Chisel: 6.6.0
- firtool: 1.73.0
- Scala: 2.13.15

## Actual behavior

After `--repl-seq-mem`, the companion output only contains memory geometry / port information such as:

- `name`
- `depth`
- `width`
- `ports`
- `mask_gran`

but no initialization-file path.

This means a downstream tool can generate an external memory module, but cannot emit `$readmemh(...)` for a memory that originally used `loadMemoryFromFileInline`.

## Minimal reproducer shape

In Chisel, the memory is created like this:

```scala
val rom = SyncReadMem(byteTableDepth, UInt(32.W))
loadMemoryFromFileInline(rom, romFile)
```

Then SystemVerilog is emitted with:

```scala
ChiselStage.emitSystemVerilogFile(
new Top,
firtoolOpts = Array(
"--repl-seq-mem",
"--repl-seq-mem-file=out.sv.conf"
)
)
```

## Observed companion output

The generated `.sv.conf` contains entries like:

```text
name some_memory_ext depth 8192 width 32 ports read
```

No initialization-file field is present.

The generated SystemVerilog only contains an external-memory placeholder such as:

```verilog
// external module some_memory_ext
```

so the original `$readmemh(...)` information is no longer available to downstream tools.

## Functional impact

Without `--repl-seq-mem`, the memory initialization is preserved in the generated Verilog.

With `--repl-seq-mem`, the initialization-file information is not preserved in the companion output, so a downstream external-memory flow cannot reconstruct equivalent behavior.

## Question

Is this an intended limitation of `--repl-seq-mem`, or should memory-file initialization metadata be preserved in the companion output?

Start by reproducing the Chisel example with firtool 1.73.0 and --repl-seq-mem, then inspect the generated .sv.conf and SystemVerilog companion output. Trace how loadMemoryFromFileInline metadata is handled during sequential-memory replacement; done means the companion output preserves enough initialization information for downstream $readmemh generation, or the limitation is documented and resolved as intentional.

Written by the indexing model from the issue text.