[Feature]: Improve observability, diagnostics, and safety of the optim module

🚀 Feature Description

Improve the observability, diagnostics, and basic safety of the kornia-algebra::optim module by exposing richer optimization results, clearer termination information, and optional validation utilities. The goal is to make the optimizer easier to trust, debug, and integrate into real-world vision and geometry pipelines, without changing the underlying optimization algorithms.

📂 Feature Category

Geometry

💡 Motivation

The optim module introduced in PR #664 provides a solid functional foundation, but it currently behaves largely as a black box. Users have limited visibility into why an optimization converged, stalled, or failed, and little support for validating custom factors or Jacobians.

This makes debugging difficult, slows experimentation, and reduces confidence when integrating the optimizer into larger systems such as SLAM, bundle adjustment, or pose refinement pipelines. Improving observability and safety would significantly lower the barrier to adoption and complement ongoing benchmarking efforts.

💭 Proposed Solution

Introduce a set of usability- and safety-focused improvements, including:

• Extend OptimizerResult to expose useful diagnostics such as:

  • Cost history across iterations

  • Final gradient norm

  • More informative termination details

  • Optional per-iteration metadata (e.g. step accepted/rejected)

• Improve termination reporting to clearly distinguish convergence, divergence, numerical instability, and limit-based stops.

• Add an opt-in finite-difference Jacobian validation utility to help users debug custom factors.

• Enforce basic safety guards where applicable (e.g. automatic quaternion normalization during SE(3) optimization).

These changes focus on API design and diagnostics rather than modifying solver mathematics or performance characteristics.

📚 Library Reference

This proposal is inspired by practices used in established optimization and geometry libraries such as:

• Ceres Solver (diagnostics, Jacobian checking, termination summaries)

• g2o (factor-level residual inspection and convergence reporting)

• Sophus (safe handling of Lie group parameterizations)

🔄 Alternatives Considered

• Relying entirely on user-side logging or callbacks: this increases boilerplate and does not provide consistent or structured diagnostics.

• Deferring all diagnostics to benchmarking code: benchmarks measure performance but do not help users debug or understand optimizer behavior.

• Adding new solvers or performance optimizations: considered out of scope until the optimizer is more observable and robust.

🎯 Use Cases

• Debugging pose refinement or bundle adjustment problems where optimization fails or converges slowly.
• Developing custom factors and verifying Jacobian correctness during experimentation.
• Integrating the optimizer into SLAM, SfM, or robotics pipelines where understanding failure modes is critical.
• Making benchmark results interpretable by exposing convergence behavior, not just runtime.

📝 Additional Context

This feature builds directly on the optim module introduced in PR #664 and complements recent benchmarking work by making optimization behavior transparent and interpretable. The intent is to incrementally harden the module for real-world usage before expanding into performance- or scalability-focused work.

🤝 Contribution Intent

• I plan to submit a PR to implement this feature
• I'm requesting this feature but not planning to implement it