Migrate solver execution logging in DataFileClass.run() from print() to logging

[parthdagia05]

Migrate Solver Execution Logging from print() to logging

Summary

The run() method in API/Classes/Case/DataFileClass.py currently uses multiple print() statements to log solver pipeline progress and exception details.

While these messages are useful during development, using print() has several limitations:

• No timestamps
• No log levels (INFO / ERROR)
• No module identification
• Poor traceability when multiple solver runs interleave output
• Not suitable for structured debugging or production deployment

As the project evolves toward cross-platform support and potential coupled solver workflows (e.g., integration with OG-Core), structured logging will become increasingly important.

---

Current Behavior

Inside DataFileClass.run():

• Timing messages are printed for:
  • Preprocessing
  • LP file creation
  • Solver execution
  • CSV generation
  • Pivot table generation
  • Message preparation
• Exceptions are printed using print(ex) before being re-raised.

These messages go directly to stdout without timestamps or severity levels.

---

Proposed Improvement

Replace print() calls inside DataFileClass.run() with Python’s built-in logging module.

Specifically:

• Use logger.info() for stage completion and timing messages.
• Use logger.error(..., exc_info=True) for exception handling.
• Configure logging centrally in API/app.py using logging.basicConfig().

Important constraints:

• The solver execution logic must remain unchanged.
• The response dictionary returned to the UI must remain unchanged.
• Only server-side console output formatting should change.
• Other print() statements elsewhere in the file are out of scope for this issue.

---

Why This Matters

Structured logging provides:

• Timestamps for execution tracing
• Log levels for severity classification
• Module-level context
• Improved debugging of interleaved solver runs
• Better readiness for production or CI environments

This is a low-risk, backward-compatible refactor that improves maintainability without altering application behavior.

---

Scope

• API/Classes/Case/DataFileClass.py (run() method only)
• API/app.py (logging configuration)

No additional refactoring is proposed in this issue.