fix(linter): exclude string-literal contents from paren/quote balance checks

[trungminhdo4-glitch]

Problem

The linter in maithili_dsl/transpiler/linter.py flagged false warnings for
unbalanced parentheses and quotes when those characters appeared inside string
literals. For example, valid code such as छपाउ("(क") could produce an
unbalanced-parenthesis warning.

Additionally, only double-quote balance was checked; single quotes were not
validated.

Root cause

lint_maithili_code counted parentheses and quote characters across the full
line, including string-literal contents. Characters inside string literals
should not contribute to code-level balance checks.

Changes

• reuse _tokenize_preserving_strings, the existing string-aware tokenizer;
• count parentheses and quote balance only in non-string tokens;
• add single-quote balance validation;
• preserve the current _make_keyword_pattern-based function call-site
  detection from main;
• add focused linter and security regression tests.

Files changed:

• maithili_dsl/transpiler/linter.py
• tests/test_linter.py
• tests/test_security.py

Behavior

The change ensures that:

• parentheses and quotes inside string literals do not trigger false warnings;
• genuinely unbalanced parentheses and quotes are still reported;
• single-quoted strings receive the same balance validation as double-quoted
  strings;
• function names inside strings or longer identifiers do not count as real call
  sites;
• the existing import and execution security boundaries remain unchanged.

Validation

Validated after reconciling the branch with the current main behavior:

• tests/test_linter.py: 44 passed
• tests/test_security.py: 43 passed
• security marker suite: 7 passed
• non-smoke suite: 153 passed
• python -m compileall maithili_dsl tests: passed
• local mergeability proof against current main: passed without conflicts

The full Windows suite still has five cp1252 subprocess-output failures. The
same five failures were reproduced on the unchanged upstream baseline and are
not introduced by this PR.

GitHub Actions for the fork PR require maintainer approval before running.

Security considerations

This change reuses the existing tokenizer only for lint balance and call-site
checks. It does not alter transpilation, import validation, sandbox execution,
or dependency handling.

Security regression tests verify that code-like content inside strings remains
data and that disallowed code outside strings continues to be rejected.

Risk

Low. The change uses existing parsing infrastructure, introduces no dependency
or public API change, and is limited to the linter and its regression tests.

Closes #30

Disclosure: This contribution was prepared with AI assistance and independently
reviewed and tested locally before publication.

[alphacrack]

Really solid contribution — the fix reuses _tokenize_preserving_strings exactly as #30 suggested, adds the missing single-quote balance check, registers against the existing security marker correctly (the project runs --strict-markers, and security is declared in pyproject, so you're safe), and includes genuine negative controls. Thank you!

One test needs a fix before merge — it silently doesn't test what its name says:

def test_quote_inside_string_not_flagged():
    code = 'छपाउ("it''s ok")\n'

Inside a single-quoted Python literal, '' closes and reopens the string — adjacent-literal concatenation. The value is actually छपाउ("its ok") (verified: repr(code) shows no apostrophe), so the apostrophe-inside-double-quotes case is never exercised. The underlying behavior is correct (I checked: छपाउ("it's ok") lints clean with your change), the test just needs to construct the string it claims to:

code = 'छपाउ("it\'s ok")\n'   # escaped apostrophe

Style suggestion while you're in there (non-blocking): the rest of test_linter.py uses literal Devanagari rather than \uXXXX escapes — literals would make these tests much easier to read for the Maithili-speaking contributors this project hopes to attract.

Happy to approve as soon as the one-line test fix lands. CI run is approved on my end.

[trungminhdo4-glitch]

Thanks for catching that. You were right—the adjacent string literals removed the apostrophe, so the test wasn't exercising the intended case. I've corrected the test, added an assertion that verifies the apostrophe is present in the constructed input, reran the focused linter/security tests, and pushed the update.

[alphacrack]

Both review points are fully addressed — thank you for the careful follow-up. ✅

• The apostrophe test now uses an escaped \' and guards with assert "it's ok" in code, so it genuinely exercises an apostrophe inside a double-quoted string (the earlier version collapsed via string concatenation).
• Assertions switched to readable literal Devanagari ("गोल ब्रैकेट", "उद्धरण").
• Merge conflict reconciled against current main; the paren/quote balance now tokenizes via _tokenize_preserving_strings and correctly counts only code regions, and single-quote balance is checked too.

Verified locally: full suite is 159 passed, and ci-ok is green. Nice work — merging.