Fix KeyError when metadata.container is missing in People parser

[SS-4]

Problem

GHunt crashes with:
KeyError: 'container'

This happens because Google responses sometimes omit "metadata.container".

Fix

Replaced unsafe dictionary access:
data["metadata"]["container"]

with safe access:
data.get("metadata", {}).get("container")

Result

• Prevents crashes
• Handles inconsistent API responses
• Keeps parsing functional

Tested locally — resolves crash across multiple emails.

[SS-4]

Note: I replaced multiple unsafe accesses in one pass because the same issue occurs in several places (emails, names, photos, etc.).

Happy to reduce this to minimal changes if preferred.

[iam-rubber-ducky]

I tested this locally on GHunt 2.3.4 and it fixes the KeyError: 'container' crash I was seeing during ghunt email.

The crash happens after authentication succeeds, inside the People API parser. The issue seems to be that Google People API can omit metadata.container on some entries.

One important detail: this does not appear to be limited to coverPhoto. In 2.3.4, similar unguarded ["metadata"]["container"] access appears in multiple paths, including email, name, readOnlyProfileInfo/profilePhotos, sourceIds, coverPhoto, and inAppReachability.

The defensive get(...) plus skip approach used in this PR seems safer than falling back to a synthetic value like "unknown", because grouping unrelated container-less entries under "unknown" could cause mis-attribution.

Validation:

• synthetic People API payload: entries without container are skipped, valid entries are parsed unchanged
• real local ghunt email test after patch: completed without the KeyError: 'container' crash

I am intentionally not including the tested email address, Google account, credentials path, tokens, cookies, session data, or OSINT results.

Happy to help test further if useful.

[iam-rubber-ducky]

Small follow-up after local testing on GHunt 2.3.4.

The metadata.container defensive handling fixes the original KeyError: 'container' crash for me. After applying the patch locally, ghunt email no longer crashes in the People API parser.

Once that blocker is fixed, a separate issue becomes visible when running the same lookup with --json:

NameError: name 'photos' is not defined

This happens later in ghunt/modules/email.py, inside the JSON export block for the email module. The Maps object includes photos and reviews, but in the current active code path those variables are not defined before the JSON object is built.

A minimal local fix that worked for me was to change the Maps export block in ghunt/modules/email.py so that photos and reviews are exported as None for now, while keeping stats unchanged:

# GHunt currently collects Maps statistics here, but detailed photos/reviews
# are not collected by the active code path. Use None to mean "not collected",
# rather than [] which would mean "checked and empty".
"photos": None,
"reviews": None,
"stats": stats

I think None is preferable to [] here because it preserves an important distinction:

• None = not collected / not available in the current code path
• [] = checked and confirmed empty

That distinction matters for OSINT output quality. Using an empty list could incorrectly imply that GHunt verified there were no photos or reviews, when this path only appears to collect the Maps statistics.

I would treat this as a separate JSON export issue. The container patch fixes the first blocker; this photos / reviews issue is simply the next problem exposed once execution gets past that crash.