fix: include custom-event meta in beacon summaries (website + mobile analyze)

[ppolezhaev]

Problem

get_website_beacons and get_all_mobile_app_beacons summarize each beacon through an essential_fields whitelist that omits meta. For CUSTOM beacons, the user-defined meta key/value pairs are the payload — they're what ineum('reportEvent', name, {meta: {...}}) reports, and what the Instana UI shows in the beacon detail panel. The tag catalog also exposes beacon.meta / mobileBeacon.meta for filtering and grouping, yet the values are unreachable in list output: every custom-event beacon comes back with browser/OS/geo context but without the data the event was created to carry.

Repro

1. Report a custom event with meta from any monitored website: ineum('reportEvent', 'my_event', {meta: {flow: 'checkout', step: 'payment'}})
2. Call get_website_beacons with beacon_type: "CUSTOM" filtered to that event.
3. The returned beacon objects contain no meta key, even though the raw /api/website-monitoring/analyze/beacons response includes it — _summarize_beacons_response drops it via the whitelist.

Fix

Add "meta" to the summarizers' field whitelists in both the website and mobile-app analyze modules. The existing empty-value skip logic already removes empty meta dicts, so beacons without meta are byte-identical to before and the summarizer's size-reduction purpose (the ~70-80% cut noted in its docstring) is preserved for non-custom beacon types.

Tests

• tests/website/test_website_analyze.py: meta survives summarization; empty meta stays omitted.
• tests/mobile_app/test_mobile_app_analyze.py: meta survives summarization.

uv run test passes (the only failure, TestVersionImport.test_version_fallback_on_exception, is pre-existing on main — it asserts a hardcoded 0.9.6 fallback against the current 1.0.0). uv run ruff check . passes.

🤖 Generated with Claude Code

[SLIBM]

@ppolezhaev meta field is actually populated with value for almost all (94–100%) beacon types, not just CUSTOM, tested on an internal IBM live tenant/instance, so the impact of this PR is growing the summarized payload 1.7–12% per type (assessed with data from this particular instance and example apps).
Basically the reduction still lands in the ~70–85% band, so this is fine - but the PR's claim that non-custom beacons are unaffected isn't accurate, and growth scales with however much meta the customer sets.

• I wouldn't consider this a blocker for merging this PR, just wanted to clarify and call out the impact.
• If meta field is needed for accessing necessary data for customer's case, at least for @ppolezhaev 's scenario, I consider this a valid request.
• Code wise, I assess this PR mergable, so @NiyathaVS @sunjit10 , if it also passes your review, I think it can be merged in.

[NiyathaVS]

LGTM!

[sunjit10]

Thanks @SLIBM @NiyathaVS for your reviews!

@ppolezhaev - There were some comments added to your other 2 PRs:
#126
#127

Since all these 3 PRs seems to be in a specific area of Instana, could you please us know if you agree with the assessment done there and we can then finalize all 3 PRs together?

[Jayssgss]

LGTM