feat(workflow-operator): export the line sources and the URL fetcher as Python

[kz930]

What changes were proposed in this PR?

File Scan, the file-scan source, Text Input and URL Fetcher implement StandaloneCodeGenerator. Each slices the raw lines before parsing, as the engine does, so a line outside the window is never converted. A boolean line is read as parseField reads one, where 1 is true and other text ends the run. A timestamp line is kept as text and parsed as a column with the helper #8597 adds, as the CSV readers parse theirs.

Two sources are reported as unverifiable rather than exported blind. File Scan takes its filenames from an input port at run time, which a source harness has nothing to feed. URL Fetcher reads a live URL, so two runs are not required to agree and a comparison would only measure the network.

Any related issues, documentation, discussions?

Part of #8325, step 12c; that issue lists the set in order. It needs #8341 for the shared source code and #8597 for the timestamp helpers, so both merge first.

Closes #8703, the task this change is the whole of.

One engine defect was found while matching these readers, and it is fixed here rather than worked around: the export alone could not close it. #8598, where a file scan extracting an archive could not also include the filename, because the line-by-line branch emitted a one-field row against the two-column schema its own flag declares. A second, #8596, where the Encoding field never reached the executor, was fixed upstream by #8605, and this branch takes that fix.

Closes #8598.

How was this PR tested?

Each operator asserts the block it emits in its own spec. Where a difference is one of behaviour rather than of text, the spec runs the engine's own executor and the generated script over the same input and compares what each produced: the boolean parsing rules and the entries read out of an archive. Once the verification lands, every operator is also run both ways on every configuration its schema offers; this branch is cut from main and does not carry that machinery, so those runs are not on this diff's CI.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 5)

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @Ma77Ball, @suyashj1231, @Neilk1021
  You can notify them by mentioning @Ma77Ball, @suyashj1231, @Neilk1021 in a comment.

[github-actions]

📊 Arrow Flight E2E bench

(no arrow-flight-e2e.csv in artifact)

Full dashboard · Workflow run

[kz930]

@carloea2 Split out of #8341 so each part reads in one sitting; the code is what you reviewed there, plus today's timestamp fixes.

[carloea2]

One text-content mismatch remains in the single-string read. Checked Python's text reader locally against the native byte-decoding path.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.70%. Comparing base (f24dab0) to head (0dcbb8d).
⚠️ Report is 80 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8705      +/-   ##
============================================
- Coverage     92.73%   92.70%   -0.03%     
- Complexity     4926     4945      +19     
============================================
  Files          1241     1243       +2     
  Lines         52476    52657     +181     
  Branches       6475     6504      +29     
============================================
+ Hits          48662    48818     +156     
- Misses         2206     2215       +9     
- Partials       1608     1624      +16     

Flag	Coverage Δ		*Carryforward flag
access-control-service	77.38% <ø> (ø)
agent-service	99.16% <ø> (ø)		Carriedforward from efb2dfc
amber	88.43% <ø> (-0.01%)	⬇️	Carriedforward from efb2dfc
computing-unit-managing-service	60.48% <ø> (+5.24%)	⬆️
config-service	87.37% <ø> (ø)
file-service	81.53% <ø> (ø)
frontend	96.53% <ø> (ø)		Carriedforward from efb2dfc
notebook-migration-service	83.73% <ø> (ø)
pyamber	98.48% <ø> (ø)		Carriedforward from efb2dfc
workflow-compiling-service	74.09% <ø> (ø)		Carriedforward from efb2dfc

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[carloea2]

The CRLF change addresses the earlier finding. A new native versus generated Text Input test fails on a Unicode separator; its LF and CRLF controls pass. The test ran with the declared #8341 shared API supplied locally.

[kz930]

@carloea2 Fixed the U+2028 split in e9d9824. The export now ends a line only at LF, CR and CRLF, like linesIterator, with a parity test over every character splitlines breaks at. Could you take another look?

[carloea2]

Retested the current head. The Unicode line separator regression is fixed. All 62 focused tests and scalafmtCheckAll pass with the #8341 source API and the existing Windows test cleanup from #8796 supplied locally. Without #8796, only that UTF-16 cleanup test fails on Windows.

Command: sbt -batch "WorkflowOperator/testOnly *FileScanOpDescSpec *FileScanSourceOpDescSpec *TextInputSourceOpDescSpec *URLFetcherOpDescSpec -- -oDF" "scalafmtCheckAll".

No new finding in the line source changes. The current checks only cover metadata, so this is not a green build confirmation. #8341 and #8597 remain prerequisites.