feat: generate TypedDict types for input-side models

[vdusek]

Summary

Adds TypedDict counterparts for input-side models so users passing plain dicts to resource-client methods get full type-checker support without importing Pydantic models.

• Generate TypedDicts alongside Pydantic models via a second datamodel-code-generator pass (--output-model-type typing.TypedDict) in poe generate-models.
• Split generated content into _models_generated.py / _typeddicts_generated.py. Hand-written _models.py / _typeddicts.py now only hold shapes not exposed by the OpenAPI spec (e.g. RequestInput, RequestInputDict).
• Extend scripts/postprocess_generated_models.py to trim the TypedDict file to input-relevant classes (plus transitive deps), rename them with a Dict suffix, and add @docs_group('Typed dicts').
• Widen resource-client input parameters (actor, task, task_collection, request_queue) to accept TypedDict | PydanticModel unions.
• Update .rules.md and manual_regenerate_models.yaml to reflect the new layout.

Closes #666.

[codecov]

Codecov Report

❌ Patch coverage is 40.35088% with 68 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.06%. Comparing base (9ab096a) to head (f10b306).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/apify_client/_typeddicts_generated.py	0.00%	49 Missing ⚠️
src/apify_client/_typeddicts.py	0.00%	19 Missing ⚠️

❌ Your patch check has failed because the patch coverage (40.35%) is below the target coverage (50.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #738      +/-   ##
==========================================
- Coverage   95.22%   94.06%   -1.17%     
==========================================
  Files          45       48       +3     
  Lines        5154     5237      +83     
==========================================
+ Hits         4908     4926      +18     
- Misses        246      311      +65     

Flag	Coverage Δ
integration	94.06% <40.35%> (-1.17%)	⬇️

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.

[vdusek]

@Pijukatel @janbuchar Let me guys know what you think, this change also has some drawbacks:

1. The postprocess script had to be extended significantly.
2. Some models and TypedDicts still need to be maintained manually, so I split them into two modules (generated vs. hand-written). I am not sure about this structure.

[janbuchar]

I think there is a case for accepting camelCase here instead - it is exactly what the API accepts. On the other hand, snake_case fits in better with the rest of the Python code and works better for the "I just don't want to look up what model I need to import" use case for TypedDicts. Did you consider this @vdusek?

[vdusek]

I think we should keep the public interface Python-idiomatic and stick with snake_case. I recently made some updates in this direction, moving the interface to snake_case, see #736.

I wouldn't have a bug problem in leaving it just as the API accepts it, but we would have to do it in all places to be consistent.

[janbuchar]

Since we shove everything into Pydantic, we should also be perfectly capable of supporting both, no? Like, camelCase and snake_case version of every model where this is applicable.

[vdusek]

I don't think so, TypedDicts don't have anything like Field(alias=...).

AI summary of what we do with the models:

The generated Pydantic models use model_config = ConfigDict(populate_by_name=True) and each field has a camelCase Field(alias=...). populate_by_name=True tells Pydantic "when constructing or validating, accept either the Python field name (snake_case) or the declared alias (camelCase)." So something like Run.model_validate({'defaultDatasetId': 'x'}) and Run.model_validate({'default_dataset_id': 'x'}) both work today. Serialization still emits camelCase (via by_alias=True) so the wire format matches the API.

But TypedDicts don't have the equivalent of Pydantic's Field(alias=...) and there's no built-in way to declare "this key may be either unique_key or uniqueKey" in a single TypedDict. We would have to generate a 2nd TypedDict for every model with camelCase keys, and then combined it via union in the input. IMO that would be horrible.

[janbuchar]

We would have to generate a 2nd TypedDict for every model with camelCase keys, and then combined it via union in the input.

Yeah, that's what I had in mind.

IMO that would be horrible.

Care to elaborate? 😁 I agree that it would increase the amount of generated code by quite a bit, but it could also be more approachable for users (even from a BC point of view).

[Pijukatel]

If it does not require so much, is the typing correct?