refactor: track structural cleanup candidates from review follow-up

[WH-2099]

Context

PR #326 uncovered several small structural cleanup patterns while addressing review feedback:

• Prefer literal match case patterns for fixed string dispatch instead of guard-based membership checks.
• Prefer public typing helpers, get_origin and get_args, over direct access to typing internals.
• Replace magic string slicing with named semantic delimiters and string APIs such as removesuffix.
• Keep protocol slicing and hash truncation unchanged unless there is a separate behavioral reason.

This issue tracks the broader cleanup candidates found during a repository-wide scan after that review.

High-confidence candidates

1. examples/notion_datasource/datasources/utils/notion_extractor.py

   _extract_page_metadata still has a long if / elif chain over prop_type for Notion property formatting. This is the closest follow-up to the PR review comment: fixed Notion property types are being used as a dispatch table. Convert it to match case where it improves readability, including literal OR patterns for closely related property types.

2. src/dify_plugin/core/documentation/generator.py

   _extract_referenced_types, _is_container_type, and _get_container_name still inspect __origin__ and __args__ directly. _format_type_name already moved to get_origin / get_args; bring the remaining helper methods in line with that approach and consider sharing small local helpers if it reduces duplication.

3. examples/google_calendar_trigger/provider/google_calendar_trigger.py

   _parse_rfc3339 rewrites trailing Z with text[:-1] + "+00:00". Replace the magic slice with a named suffix constant plus removesuffix, or another explicit string API that makes the delimiter semantic.

Medium-confidence candidates

4. examples/notion_datasource/datasources/utils/notion_client.py

   Page and database icon / parent handling contain repeated type-based branches. This likely wants a small helper for icon normalization and parent resolution rather than a mechanical match case rewrite.

5. src/dify_plugin/core/entities/plugin/request.py and src/dify_plugin/interfaces/agent/strategy.py

   Both convert prompt message roles to concrete prompt message classes through nearly identical role dispatch. Consider a shared mapping or helper so the role-to-class relationship is defined once.

6. src/dify_plugin/interfaces/model/openai_compatible/llm.py

   function_calling_type dispatch appears in several places for function_call and tool_call. A local helper or constants may be better than repeatedly rewriting small branches to match case.

7. src/dify_plugin/plugin.py and src/dify_plugin/integration/run.py

   These contain enum dispatch chains that might read better as match case, but they should be evaluated case by case. Keep the current form if matching does not make the control flow clearer.

Non-goals

• Do not change hash or SHA truncation such as hexdigest()[:16] or sha[:7]; those slices express fixed display or identifier lengths.
• Do not change stream or protocol buffer slicing such as lines[:-1] or lines[1:] as part of this cleanup; those are stateful parsing operations and need separate behavioral review.
• Do not force match case for type-object matching when a guard is clearer. For example, case _ if origin in COLLECTION_ORIGINS is acceptable because the subject is a type object, not a fixed string literal.

Acceptance criteria

• Use literal OR patterns for fixed string dispatch where practical.
• Replace remaining typing internals in documentation generation with public typing helpers.
• Remove magic string slices only when there is a named semantic suffix or delimiter.
• Prefer helper extraction where the same dispatch logic is repeated in multiple places.
• Keep unrelated protocol parsing, hash truncation, and broad behavioral refactors out of scope.
• Run just check before closing.