Fix file-variable CLI flag and header ID setup

[ryanchou1994]

--use-file-vars now works as a flag. Previously argparse expected a value, so placing it before an input filename consumed the filename; using it with stdin or after a filename failed with a missing-argument error.

This also fixes a crash when an Emacs-style file variable enables header-ids. Those options are loaded after construction, so they need the same normalization as constructor extras before heading rendering. The shared helper preserves initialization behavior and existing reset-count settings.

Related to #365 and #269. This addresses the CLI flag and header-id file variables, rather than every file-variable extra. The README includes a working command and modeline example.

Compatibility: the flag no longer accepts a value. A token after --use-file-vars is an input path; --use-file-vars=VALUE is rejected.

Validation:

• Regression tests failed on the base: five CLI failures and one API error, with the no-flag control passing.
• Mac Python 3.13.13: make testone passed 275 tests; the seven existing ReDoS regressions passed.
• Linux Python 3.13.15: the same 275 functional tests, seven existing ReDoS tests, internal doctests, and 12 installed-wheel API/CLI checks passed. All 887 source file hashes matched before and after validation.
• New CLI tests pass pycodestyle. The two existing changed Python files retain the same 475 pre-existing pycodestyle diagnostics, with none added.
• Wheel and source distributions build; Twine passes with the existing missing long_description_content_type warning.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[nicholasserra]

So is this backwards compatible? Your comment about compatibility made me question whether the --use-file-vars flag took some kind of input, but it appears it doesn't?

Otherwise LGTM

[ryanchou1994]

Yes, apart from one odd form. --use-file-vars is a plain boolean flag now (action="store_true"). Before this change the argument had no action, so argparse required a value: markdown2 --use-file-vars foo.md swallowed the path as the flag's value and read stdin instead, and putting the flag after the path errored with "expected one argument". The only way it ever worked was to pass a throwaway value, e.g. --use-file-vars 1 foo.md, and that form now treats 1 as an input path. That is the compatibility note in the description. The library API (use_file_vars=True) is unchanged.

[nicholasserra]

Thanks!