Make AttentionModuleMixin.set_attention_slice callable

[ayo0la]

What does this PR do?

AttentionModuleMixin.set_attention_slice referred to two names the mixin never defined, so it raised AttributeError for every argument:

• self.default_processor_cls() — the class attribute is _default_processor_cls.
• self._get_compatible_processor("sliced") — no such method existed anywhere in src/.

Nothing routes into the method today (the models that recurse into submodule set_attention_slice all hold attention_processor.Attention, which has its own working implementation), so this is latent. It stops being latent as soon as a model built on AttentionModuleMixin is wired into enable_attention_slicing, which the TODO in modeling_utils.py points toward.

This PR keeps the shape the method already described in its own comments rather than inventing a new one:

• Fixes the typo so set_attention_slice(None) restores _default_processor_cls, matching the legacy Attention.set_attention_slice.
• Adds _get_compatible_processor(processor_type, **init_kwargs) on the mixin. It looks through _available_processors for a class whose name contains the requested type ("sliced" matches SlicedAttnProcessor-style names) and instantiates it with the given kwargs, or returns None.
• When slicing is requested but the module lists no sliced processor, it falls back to the default processor as the original comment intended, but now logs a warning naming the module class, so enable_attention_slicing() no longer silently becomes a no-op for that model. No AttentionModuleMixin subclass in the tree currently ships a sliced processor, so today every mixin-based module takes the warning path; the lookup means one that adds a sliced processor gets picked up without touching the mixin again.

Raising instead of falling back was the other option. I did not take it because DiffusionPipeline.enable_attention_slicing calls set_attention_slice on every submodule that has the method, so a raise would make that pipeline-level call crash for any pipeline holding a mixin-based model. Happy to switch to a raise if you would rather have the loud failure.

Tests added in tests/models/test_attention_processor.py using a tiny in-test AttentionModuleMixin subclass (no checkpoints, CPU only): None restores the default, an available sliced processor is used with the right slice_size, the no-sliced-processor path falls back and warns, the sliceable_head_dim guard still raises, and _get_compatible_processor returns the instance or None.

Fixes #14729

Before submitting

• Did you use an AI agent (Claude Code, Codex, Cursor, etc.) to help with this PR? If so:
  • Did you read the Coding with AI agents guide?
  • Did you run the self-review skill on the diff?
  • Did you share the final self-review notes in the PR description or a comment? (below)
• Did you read the contributor guideline?
• Was this discussed/approved via a GitHub issue? AttentionModuleMixin.set_attention_slice references two attributes that do not exist #14729
• Did you write any new necessary tests?

Who can review?

@DN6 @yiyixuxu

Self-review notes

Reviewed the diff against .ai/references/review-rules.md and models.md/testing.md.

• Blocking: none found.
• Non-blocking, left for review: the fallback-and-warn choice when a module has no sliced processor (versus raising). Deliberate, reasoning in the description above.
• Non-blocking, left for review: _get_compatible_processor matches on class name substring. This mirrors the existing "Added" in processor.__class__.__name__ check in fuse_qkv_projections, so it is consistent with how the mixin already classifies processors, but a registry attribute would be more explicit if you want that.
• Dead code: none added. _get_compatible_processor has one caller (set_attention_slice) and is exercised directly by test_get_compatible_processor.
• Docs: no public API surface changed. set_attention_slice was already documented; its docstring still describes the behavior.
• Verified: make quality clean (ruff, doc-builder style, check_doc_toc, check_ai), tests/models/test_attention_processor.py 7 passed on CPU (torch 2.14.0+cpu, Python 3.12), and the reproduction from the issue now prints AnimaTextConditionerAttnProcessor for both None and 1, with the warning on the 1 path.