Map global variable receivers to their classes

[sirreal]

Method_Call_Reflector::_getClassMapping() maps well-known WordPress globals to their classes with keys like 'wpdb', but the pretty-printed receiver it is matched against is '$wpdb' — the comment documenting the list's generation even shows the sed "s/\\$//g" stage that stripped the sigils. The $wp_globals half of the mapping has therefore never matched; the existing test pinned the fallout (class => '$wpdb'), evidently unintentionally. The $wp_functions half (get_current_screen() → WP_Screen) was unaffected.

The keys now carry the $ sigil, so the mapping matches. This is a deliberate behavior change to exported uses.methods[].class for calls on these globals:

• Where the variable name differs from the class — $wp_the_query, $post, $authordata, $userdata, $wp_customize, $wp_hasher, $wp_json, $phpmailer, $custom_background, $custom_image_header — the exported class (and thus the method slug built from it) now points at the real method post. Those cross-links have been broken all along.
• Where they coincide ($wpdb, $wp_query, …) only the exported string changes ($wpdb → wpdb); the link slug was already rescued by sanitize_title() dropping the $.

The alternative — deleting the dead half — was considered and rejected: the mapping repairs real cross-links. A corpus regeneration diff will show class-name changes for these receivers; they are intended.

The updated $wpdb expectation and the new $wp_the_query → WP_Query assertion fail on master and pass with the fix; the full suite passes.

Found by the multi-agent review during #262; extracted as a standalone change.

🤖 Generated with Claude Code