feat: add progress_callback to wait_processed() for real-time progress monitoring

[nayagamez]

Summary

• Add optional progress_callback parameter to wait_processed() throughout the client chain
• Add total property to QueueStatus for convenient progress calculation
• Fully backward compatible — existing callers are unaffected

Motivation

When wait_processed() blocks for long-running indexing operations (e.g., hundreds
of files), callers have no way to report progress to users. The internal queue status
(pending, in_progress, processed, error_count) is already tracked but only
returned after completion.

This change exposes that status during the wait loop via an optional callback, enabling
callers to build accurate progress bars, logging, or monitoring dashboards.

Changes

• QueueStatus: add total property (sum of all state fields)
• QueueManager.wait_complete(): add progress_callback parameter, invoked each poll iteration
• ResourceService.wait_processed(): adapt QueueStatus → dict at boundary, thread callback
• BaseClient / LocalClient / HTTPClient: update abstract signature and implementations
• AsyncOpenViking / SyncOpenViking: thread parameter through

Example Usage

def on_progress(status):
    for queue_name, s in status.items():
        pct = (s["processed"] / s["total"] * 100) if s["total"] > 0 else 0
        print(f"{queue_name}: {pct:.0f}% ({s['processed']}/{s['total']})")

client.wait_processed(timeout=600, progress_callback=on_progress)

Test plan

• QueueStatus.total property returns correct sum
• Callback invoked on each poll iteration with correct status dict
• No callback (None) works identically to current behavior
• Timeout still works with callback provided
• ResourceService adapts QueueStatus → dict with total field
• HTTPClient accepts parameter without error (no-op)
• Existing tests pass unchanged

All tests in tests/client/test_wait_progress.py (10 tests, 3 test classes).

[CLAassistant]

All committers have signed the CLA.

[MaojiaSheng]

Thanks, @nayagamez but we have a concern that, we are working with server/client arch, and this PR depends on a embed mode. If one day the Queue is on a remote server, your contribution will cause fail.

I suggest more decouple design on this issue.

[MaojiaSheng]

Another idea is that, wait_processed callback should be implemented after #115 transaction. After that, we can register a event queue for each transaction, and then you can get events for the transaction.