[warreveys]

Summary

Custom tasks could not use a language or input type that WorkRB does not ship, because Language and ModelInputType were closed enums (#56).

This keeps both enums and adds a register() classmethod, as agreed on the issue:

from workrb.types import Language, ModelInputType

Language.register("sw")
COURSE_TITLE = ModelInputType.register("course_title")

MyTask(languages=["sw"])

• Registered values resolve through the normal Language("sw") lookup, so no task or model code changes. Everything is contained in src/workrb/types.py.
• Unregistered values still raise ValueError, so typos such as languages=["deu"] are still caught.
• Values must be non-empty lowercase strings, so case variants cannot become separate result rows.
• Registering a value that already exists returns the existing member.
• Existing members and behaviour are unchanged.

Limitations

• The registry is global, so call register() once at import time.
• Registered values do not appear when iterating the enum (list(Language)), and "sw" in Language does not reliably see them across Python versions. Use Language("sw") to check a value.

Docs and example

• README and CONTRIBUTING describe when and how to register a value, and how to define a custom task group by subclassing BaseTaskGroup.
• examples/custom_task_example.py now uses a registered input type and its own task group.
• The README diff also contains formatter-only changes to existing code blocks.

Testing

• New tests/test_types.py covers lookup, idempotent registration, isolation between the two enums, rejected values, pickling, and a task that uses a registered language, input type and custom task group.
• poe lint passes.
• Registered members were also checked on Python 3.10 through 3.14 (identity, pickle, copy, hashing, JSON).

Closes #56

[warreveys]

@workforcedeveloper

Converted your issue to a PR. What are your thoughts on this?