[DO NOT MERGE] Handle JSON conversion failures IO vs unmappable EBCIDIC bytes

[Gautham-coder]

Proposed changes

Fixes JSON response truncation and a high-CPU loop when streaming dataset records that contain unmappable EBCDIC bytes. A single bad byte in one record previously latched a shared error flag that suppressed all further output, truncating the entire response (EOF found inside string constant). This splits the error handling so data-conversion failures no longer gate output, while real IO errors still hard-stop, and adds a bounded loop so a dataset that fails every record can't spin
the CPU.

Changes

File	Change
h/json.h	Added dataConversionErrorFlag to jsonPrinter_tag; declared jsonSetDataConversionErrorFlag, jsonCheckDataConversionErrorFlag, jsonClearDataConversionErrorFlag
c/json.c	Conversion failure in jsonConvertAndWriteBuffer now sets dataConversionErrorFlag (not ioErrorFlag) and writes a blank placeholder instead of suppressing output; write failure still sets ioErrorFlag; added the 3 flag accessors; both flags reset in jsonPrinterReset
zss/c/datasetjson.c	Record loop blanks bad records and continues, clears the conversion latch each record, and enforces a hard cap (MAX_CONSEC_CONVERSION_FAILURES = 100) with a warning log

Resulting Behavior

Scenario	Before	After
One / a few bad records (unmappable byte)	Entire response truncated mid-string (EOF found inside string constant)	Bad record blanked, streaming continues, full response completes
Every record fails (e.g. SVC dump of unmappable bytes)	High-CPU runaway loop to EOF	Loop aborts after 100 consecutive failures and logs a warning
Real IO error (broken socket)	Loop stops, all output suppressed	Unchanged — ioErrorFlag still hard-stops everything

This PR addresses Issue: [Link to Github issue within https://github.com/zowe/zss/issues if any]

This PR depends upon the following PRs: zowe/zowe-common-c#675

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Change in a documentation
• Refactor the code
• Chore, repository cleanup, updates the dependencies.
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

PR Checklist

Please delete options that are not relevant.

• If the changes in this PR are meant for the next release / mainline, this PR targets the "staging" branch.
• My code follows the style guidelines of this project (see: Contributing guideline)
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• New and existing unit tests pass locally with my changes
• video or image is included if visual changes are made
• Relevant update to CHANGELOG.md
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works, or describe a test method below

Testing

Further comments

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud