feat: add creator() factories for the Metabase asset family

[vaibhavatlan]

Problem

MetabaseCollection, MetabaseDashboard, and MetabaseQuestion ship without a .creator()/.create() factory (they only have create_for_modification). Because there's no factory that owns the qualifiedName grammar, connectors hand-build Metabase qualifiedNames with f-strings — duplicating Atlan's QN grammar per connector. That's exactly the anti-pattern the application-sdk conformance rule P028 ManualQualifiedNameFString flags (11 live warnings on one connector today, unresolvable in the app because no upstream factory exists).

Change

Adds creators that own the grammar centrally:

Asset	creator(...)	qualifiedName
MetabaseCollection	name, connection_qualified_name, metabase_id	{connection_qualified_name}/collections/{metabase_id}
MetabaseDashboard	name, connection_qualified_name, metabase_id	{connection_qualified_name}/dashboards/{metabase_id}
MetabaseQuestion	name, connection_qualified_name, metabase_id	{connection_qualified_name}/questions/{metabase_id}

Each follows the standard pattern: creator() + a deprecated create() alias on the asset, and an Attributes.create() that builds the QN and derives connector_name.

Design note — id-based grammar (for maintainer review)

The house convention builds QN from the name ({connection_qualified_name}/{name}). The Metabase creators instead use an id-based grammar with a typed segment (/collections/{metabase_id}), because that is the qualifiedName connectors already write in production — a name-based grammar would not match existing assets and would break dedup/lineage on adoption. This PR effectively establishes the canonical Metabase QN grammar; flagging it explicitly in case maintainers prefer a different shape.

What's included

• Generator method templates (source of truth): methods/asset/metabase_{collection,dashboard,question}.jinja2 + methods/attribute/....
• The regenerated creator methods on the three asset classes (+ required imports).
• Parametrized unit tests per asset: creator, deprecated-create warning, missing-parameter validation, and create_for_modification / trim_to_required. 24 tests, all passing; ruff check clean; black-formatted.

Notes

• The metabase_id is typed str (callers stringify the Metabase system id).
• Left HISTORY.md untouched — it looks release-curated; happy to add an entry in whatever form you prefer.
• Collection/dashboard relationship wiring (e.g. a dashboard's parent collection) is intentionally out of scope for this first cut; creators are connection-rooted. Can add optional relationship params in a follow-up.

[linear]

BLDX-1558

[vaibhavatlan]

Update: mirrored into pyatlan_v9 + generation verification

pyatlan_v9 now included (the package the metabase connector actually imports). v9 uses the _overlays/ mechanism + flat asset classes, so this adds:

• pyatlan_v9/model/assets/_overlays/metabase_{collection,dashboard,question}.py (creator source of truth)
• the merged creator/create/create_for_modification on the three flat asset classes (imports from pyatlan_v9.utils; connector_name derived by splitting the connection QN, matching the v9 PresetWorkspace pattern)

Same id-based, production-matching grammar on both sides. Verified functionally on both packages:

pyatlan   : default/metabase/1/collections/9
pyatlan_v9: default/metabase/1/collections/9

"Nothing else changes" verification (pyatlan generator): module.jinja2 resolves per-asset method templates by asset name — methods/asset/<entity_def.name | to_snake_case>.jinja2. The six new templates are metabase-named only, so regeneration can affect only the three Metabase asset files; no other asset's rendering can change. A full regenerate against real typedefs still needs a tenant (ATLAN_BASE_URL/ATLAN_API_KEY); the committed tests/unit/data/typedefs.json is a reduced fixture and is not suitable for a full clean regen.

[vaibhavatlan]

Verified against a real tenant

Generator (source-of-truth check). Ran uv run ./generator --override against a live tenant (which ships all three Metabase entity defs). The three Metabase asset files regenerate from the .jinja2 templates as follows:

• metabase_dashboard.py, metabase_question.py → byte-identical to what's committed.
• metabase_collection.py → identical except one stray blank line in the imports that the generator does not emit — fixed in 0643308.

All creator / Attributes.create bodies come straight from the templates and reproduce exactly, so the templates are confirmed as the source of truth. (The rest of the generator diff was unrelated typedef drift from a newer tenant baseline and was discarded.)

Integration tests (0fbcb36). Added tests/integration/metabase_asset_test.py — connection-rooted coverage for all three creators: seeds one of each under a live Metabase connection, asserts the id-based qualifiedName grammar + connector_name, then exercises certificate/announcement update, retrieve, delete and restore.

7 passed in 77.24s

Confirms the assets actually seed and round-trip on a real tenant.

[Aryamanz29]

LGTM - thanks!