chore: add PEP 484 type annotations to modifierservice.py

[yehorcallmedai-maker]

Continuing the type annotation pass from #377 (logservice.py) and #378 (systemservice.py).

What this changes

Adds PEP 484 type annotations to all 7 static methods in ModifierService. No logic changes.

blender_object / armature_object → bpy.types.Object (requires fake-bpy-module per requirements-dev.txt)
modifier return values (create_modifier, create_armature_modifier, create_mask_modifier, create_subsurf_modifier) remain Any — specific subclass attributes (.object, .vertex_group, .levels) are not on bpy.types.Modifier base; typed returns are a follow-up
modifier_name, modifier_type, vertex_group → str
show_in_editmode, show_on_cage, move_to_top → bool
levels, render_levels → int
Added from typing import Any import
Added # type: ignore[arg-type] on the modifiers.new() call — fake-bpy-module types the second argument as ObjectModifierTypeItems (a Literal union), not plain str; a cast here felt like scope creep

Pyright result
Baseline (before): 1 error, 0 warnings (bpy import unresolvable outside Blender)
After amendment: 0 errors, 1 warning — bpy.types.Object annotations with fake-bpy-module installed resolve the import, eliminating the error

[joepal1976]

Regarding the "Any" part... If installing the fake-bpy-module per the https://github.com/makehumancommunity/mpfb2/blob/master/requirements-dev.txt file, pyright accepts "bpy.types.Object" as type hint.

Now, I'm new to pyright and haven't really done a lot of work with type hinting either. I'd love to hear your input on this. Is it a bad idea to rely on fake-bpy-module?

[yehorcallmedai-maker]

Good catch — I've updated the commit to use bpy.types. Object for blender_object and armature_object parameters, as you suggested.
One thing to flag: switching from Any to bpy.types.
Object caused pyright to surface a new type mismatch on the blender_object.modifiers.new(name, type) call inside create_modifier. The type parameter is typed by fake-bpy-module as ObjectModifierTypeItems (a Literal union of valid modifier strings), not plain str. Since create_modifier is a generic factory that accepts arbitrary modifier type strings, I've added a # type: ignore[arg-type] on that one call rather than changing the public signature to ObjectModifierTypeItems — that felt like scope creep for this PR.
The modifier return types (create_modifier, create_armature_modifier, etc.) remain Any. Changing them to bpy.types.Modifier would cause pyright to error on attribute accesses like modifier.object and modifier.vertex_group inside those methods, since those attributes are on specific subclasses only. That's a follow-up for when we annotate the full method bodies.

Baseline (before): 1 error, 0 warnings (bpy import unresolvable outside Blender)
After amendment: 0 errors, 1 warning — the bpy.types.Object annotations with fake-bpy-module installed actually resolve the import, eliminating the error