lobster_rst_report escapes list-table rows inside requirement text and produces invalid RST

## Summary

When a requirement description contains a valid nested `.. list-table::`, the generated multi-page Lobster RST report escapes the table row markers (`* -` becomes `\* -`), and Sphinx/docutils then rejects the generated page.

## Observed behavior

Generated file:
`traceability_report/feature_requirements.rst`

Error:
`Error parsing content block for the "list-table" directive: exactly one bullet list expected.`

In the generated report, the table body is rendered with escaped row markers like:

```rst
.. list-table::
:header-rows: 1

\* - #
- Mode 0
- Mode 1
```

instead of valid rows:

```rst
.. list-table::
:header-rows: 1

* - #
- Mode 0
- Mode 1
```

## Expected behavior

Nested RST table content inside requirement text should remain valid in the generated traceability report.

## Why this looks like a tooling bug

- The original requirement page renders the table correctly.
- The failure appears only in the generated Lobster RST report.
- The generated report escapes markup that must remain structural RST.

## Impact

Valid migrated requirement content cannot be reused safely in Lobster-generated report pages if it contains structured RST tables.

## Reproduction hint

A feature requirement with a description containing:
- prose
- a nested `.. list-table::`
- normal `feature_requirements` generation
- dependable element / Lobster traceability report generation

## Suspected area

`tools/lobster_rst_report` rendering / escaping logic for requirement text embedded into report pages.

Start in tools/lobster_rst_report and trace the rendering or escaping path for requirement text embedded in traceability_report/feature_requirements.rst. Reproduce with a requirement containing a nested .. list-table::, then verify that the generated table keeps unescaped row markers and is accepted by Sphinx/docutils.

Written by the indexing model from the issue text.