MarkdownNodeParser misses headings indented by 1–3 spaces and loses their hierarchy

Finding: In an external report (not reproduced by KFA), MarkdownNodeParser in llama-index-core 0.14.25 (Python 3.12.14, macOS arm64) is said to treat ATX headings indented by 1-3 spaces as plain body text, which loses the section boundary and the parent path of later headings [https://github.com/run-llama/llama_index/issues/23411]. The reporter says current main has equivalent parser code, but that is the reporter's statement and no fixed release is identified. Reported reproduction: the input is a document with '# Root', intro text, an indented ' ## Child' heading, body text, then '### Leaf'. Per the report, the parser returns two nodes instead of three. The indented Child heading stays inside Root's body, and Leaf gets header_path '/Root/' instead of the expected '/Root/Child/'. The same text without indentation is said to yield three sections [https://github.com/run-llama/llama_index/issues/23411]. Impact as reported: the text is retained, so there is no data deletion. The defect is wrong chunk boundaries and wrong hierarchy metadata. The reporter describes this as a local public-API reproduction on a technical-document sample, not a production incident [https://github.com/run-llama/llama_index/issues/23411]. Reference behavior cited: the reporter points to CommonMark section 4.2, which allows up to three leading spaces before an ATX heading, while four spaces must not count as heading indentation [https://github.com/run-llama/llama_index/issues/23411]. Suspected cause (hypothesis, not maintainer-confirmed): the reporter says the heading regex begins with ^(#+), so it only matches '#' in column zero [https://github.com/run-llama/llama_index/issues/23411]. Status: the issue is open. The only comment is from a non-maintainer (association NONE) who offers to change the regex to allow 0-3 leading spaces and add a regression test, and asks for assignment [https://github.com/run-llama/llama_index/issues/23411#issuecomment-6069038086]. The reporter's proposed scope is 0-3 ASCII spaces outside code fences, keeping the current treatment of 4+ spaces and fenced code, with no other grammar changes [https://github.com/run-llama/llama_index/issues/23411]. This is a proposal only. No fix commit or release appears in the supplied sources. Limitations: this is an external report with no KFA reproduction. The reporter says the reproduction and tests were AI-assisted and run locally. Eleven focused tests reportedly give six failures and five passing controls, and seven existing Markdown parser tests pass, but the full core suite was not run [https://github.com/run-llama/llama_index/issues/23411]. Related PRs #23323, #23362 and #23283 are mentioned by the reporter and were not independently checked. No workaround is stated.