fix: forward missing run kwargs in Actor.start/call/call_task

[vdusek]

Summary

ActorClient.call (apify-client) exposes several run-configuration kwargs that the SDK wrapper Actor.call was silently dropping, forcing users to bypass the SDK and reach into Actor.apify_client.actor(id).call(...) (e.g. to set max_total_charge_usd for pay-per-event Actors — see the user report).

This patch wires through the missing parameters so the SDK API matches the underlying client:

• Actor.start / Actor.call — adds max_items, max_total_charge_usd, restart_on_error, force_permission_level
• Actor.call_task — adds max_items, restart_on_error (the task endpoint has no max_total_charge_usd / force_permission_level)

Docstrings updated to match. No change to existing kwargs or call semantics; pyproject apify-client constraint unchanged.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.01%. Comparing base (f394c75) to head (6211639).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #906   +/-   ##
=======================================
  Coverage   87.01%   87.01%           
=======================================
  Files          48       48           
  Lines        2942     2942           
=======================================
  Hits         2560     2560           
  Misses        382      382           

Flag	Coverage Δ
e2e	37.72% <ø> (ø)
integration	59.04% <ø> (ø)
unit	75.76% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MatousMarik]

Seems ok to me.

One concern though: this approach of manually mirroring kwargs from the
client is fragile — next time the client adds a parameter, someone has to
remember to update the SDK too. Would it be possible to extract the
"passthrough" subset into a shared TypedDict and use **kwargs:
Unpack[RunConfig]? That would make the boundary explicit and future-safe.

Also, was a full audit done against the current client signatures? This PR
fixes the reported case, but are we confident there are no other missing
args across start / call / call_task right now?

[janbuchar]

PPR is effectively removed now. Maybe we don't need to add this parameter?

[vdusek]

Not a strong opinion, but I'd prefer to mirror the behavior of the client (and the API) here. If PPR is being removed, the right path is to introduce a deprecation warning pointing users to PPE, and then drop it in the next major. So I'd rather keep it for now and follow a proper deprecation process later.

[vdusek]

One concern though: this approach of manually mirroring kwargs from the client is fragile — next time the client adds a parameter, someone has to remember to update the SDK too. Would it be possible to extract the
"passthrough" subset into a shared TypedDict and use **kwargs: Unpack[RunConfig]? That would make the boundary explicit and future-safe.

It's fragile, but that's the trade-off if we want to propagate methods and arguments downstream. This is the approach that was established here before I joined, so we're just continuing consistently. The typed-dict alternative has its own drawbacks, too. If we want to rethink this, I would challenge the "propagate methods and arguments downstream" approach itself.

Also, was a full audit done against the current client signatures? This PR fixes the reported case, but are we confident there are no other missing args across start / call / call_task right now?

Everything should be addressed now (if I didn't overlook anything).