feat(flickr): extract the profile's linked social accounts

[brunolm]

A Flickr profile carries dedicated fields for five other platforms — facebook, instagram, twitter, tumblr, pinterest — plus occupation. validate_flickr extracted none of them.

thomashawk    ->  facebook: thomashawk   instagram: thomashawk   twitter: thomashawk
                  tumblr: thomashawk     pinterest: thomashawk
kennethreitz  ->  occupation: Software Engineer   (only populated field)

Each value names an account on a different site, which is what turns a hit from "this handle exists here" into a lead.

This needs a second request, contrary to what it looks like

The module fetches /photos/{user}. The social fields are not on that page at all — they live only in the person-public-profile-models block served by /people/{nsid}/. A page-wide search of /photos/thomashawk for facebook / instagram / tumblr returns only Flickr's own SDK config.

So the enrichment is a second, best-effort request made only after the account is already confirmed found, in the same shape as stripchat._api_profile and camsoda._broadcaster_profile. The verdict path is unchanged: a blocked or restructured /people/ page costs metadata, never a verdict, and a miss never triggers the extra request.

Extraction is anchored to the owner, because the page embeds 34 other people

/people/51035555243@N01/ carries 35 person models — the owner plus 34 contacts, with 25 distinct realname and 25 distinct pathAlias values belonging to other users. Taking the first match, or sweeping the document, would attribute a stranger's Instagram to the scanned account.

The lookup matches on the owner's NSID, taken from the already-verified photostream owner:

for entry in _main_models(text).get("person-public-profile-models") or []:
    data = (entry or {}).get("data")
    if isinstance(data, dict) and str(data.get("id") or "") == nsid:
        return data

Running the same lookup with each of the 34 contact NSIDs returns {} in every case, and each emitted handle agrees with its *Url sibling in the matched object. Addressing the request by NSID also makes the whole thing casing-proof — ThomasHawk and thomashawk return identical output.

Handles are stored bare, not as URLs

Flickr stores "thomashawk", not https://twitter.com/thomashawk, and the values pass through unchanged rather than being expanded into a guessed URL shape per platform.

Testing

Verified live against a profile with all five fields set, one with only occupation, one with none (keys absent, not empty strings), both casings of the same handle, the NSID form, and a nonexistent handle (unchanged available).

Not verified

No profile was found whose social fields contain a full URL rather than a bare handle. If such an account exists the value passes through as-is, but there is no live example to confirm the shape.