Make the default silent-chunk-drop on parse errors discoverable

[ojassharma7]

Description

extract()'s default (suppress_parse_errors=True) drops a chunk on a parse or schema error with no exception raised — the chunk's data is simply missing from the result. This is easy to miss: any caller-side retry logic written around catching a parse exception from extract() never fires, because the exception never reaches it.

Traced and reported by @reichaves on #358, after independently hitting it in reichaves/langextract-fundos — not a bug, an existing knob (resolver_params={'suppress_parse_errors': False}) that just wasn't visible enough. No behavior change — only visibility of the existing default, per that comment: "Might be worth a doc callout or a debug-level log distinguishing 'chunk silently dropped, no retry possible' from other warnings."

• resolver.py: the two warning-level log lines now say the data is gone and cannot be retried, and name the exact opt-out, instead of just "Skipping chunk: ...".
• extraction.py: extract()'s docstring gets a Note: callout right after the summary — ahead of the full Args list — instead of the behavior being reachable only via one line buried under resolver_params.

Related to #358

Type: Documentation (log-message wording + docstring only; no behavior change).

How Has This Been Tested?

New regression test asserting the parse-error log message names both "no retry possible" and the opt-out; the existing schema-error log test is strengthened the same way.

$ python -m pytest tests/resolver_test.py

Differential-clean against the full suite: 765 passed (up by exactly this PR's one new test), same 42 pre-existing/environmental failures as main (missing optional openai extra + 3 plugin-packaging tests), none new. pyink + isort + pylint --rcfile=.pylintrc / --rcfile=tests/.pylintrc (CI's exact configs) all clean.

Checklist:

• I have read and acknowledged Google's Open Source Code of conduct.
• I have read the Contributing page and am covered by the Google Individual CLA (signed for Forward Gemini generation settings #509).
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach. — this is @reichaves's own suggested fix, verbatim from the comment on Challenges extracting structured data from large Brazilian fund regulation PDFs (230K+ chars, 22 entity types) #358.
• I have made any needed documentation changes (the Note: callout is the fix).
• I have added tests covering the changes.
• I have followed Google's Python Style Guide and ran pylint over the affected code.