Fix listing detection to use inheritance check instead of name suffix

[lucaslyl]

linear:https://linear.app/cardstack/issue/CS-10067/islistingcard-check-incorrectly-flags-cards-with-listing-in-name

Problem:

Previously there is an airbnbListing card (airbnb-listing.gts) doesn't show the "Create listing with AI" button in the menu. After investigating, I found that the isListingCard function checks whether the class name ends with "Listing" to determine if a card is a catalog listing. I think we can improve this function since users may create their own cards with class names ending in "Listing".

Changes

The new implementation (renamed to isListingSubclass) traverses the inheritance chain using getAncestor() and checks if any ancestor's module path includes 'catalog-app/listing/listing'. This correctly identifies only cards that actually inherit from the catalog Listing base class.

Before:

Screen.Recording.2026-01-16.at.5.03.45.PM.mov

After:

[github-actions]

Host Test Results

    1 files  ±0      1 suites  ±0   1h 39m 3s ⏱️ -49s
1 875 tests ±0  1 860 ✅ ±0  15 💤 ±0  0 ❌ ±0 
1 890 runs  ±0  1 875 ✅ ±0  15 💤 ±0  0 ❌ ±0 

Results for commit 1fa01e9. ± Comparison against base commit 1e61006.

[habdelra]

this isn't a very precise check. the dir it's checking for is not rooted and we are not making any assertions about the origin of the URL. it's also awkward that a card needs to delegate to logic in its enclosing card in order to render a thing that is specific to the enclosing card. usually delegation works in the opposite direction. is there a better way we can supply this functionality by having the listing card actually provide the menu items as opposed to having this card provide listing menu item--maybe like a {{yield}}. my fear is that this card will be a dumping ground for menu items for all sorts of other cards if they also follow this same pattern. it also probably exposes a short coming in the API if this card needs to change in order to provide menu items for other cards