[BUG] CVP Passport migration regresses verified IDV records to denied

### Preflight Checklist

- [x] I searched existing issues. The reports linked below describe related post-migration symptoms, but none documents the same verification ID changing from `VERIFIED` to `DENIED`.
- [x] This is a single bug report: incorrect CVP state migration/reconciliation in the Verification Portal / Passport backend.
- [ ] Latest Claude Code version. This is a server-side Passport state bug observed with Claude Code 2.1.258; the current release is 2.1.259.

### What's Wrong?

A previously approved Cyber Verification Program (CVP) organization was migrated into Anthropic's new Verification Portal / Passport system. Since that migration, the organization has experienced inconsistent CVP state transitions and loss of its prior approval.

The strongest evidence is that the same identity-verification record was initially returned as successfully verified:

```json
{
"verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
"verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
"programSlugs": ["cvp"],
"state": "PORTAL_VERIFICATION_STATE_VERIFIED",
"validUntil": "2027-02-04T00:00:00Z"
}
```

The exact same `verificationId` later changed to:

```json
{
"verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
"verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
"programSlugs": ["cvp"],
"state": "PORTAL_VERIFICATION_STATE_DENIED",
"completedAt": "2026-08-31T20:13:01.987176Z"
}
```

The overall CVP application now returns:

```json
{
"applicationStatus": "PROGRAM_APPLICATION_STATUS_DENIED"
}
```

The same response also reports the use-case verification as incomplete rather than denied:

```json
{
"verificationType": "VERIFICATION_TYPE_USECASE_FORM_CYBER",
"programSlugs": ["cvp"],
"state": "PORTAL_VERIFICATION_STATE_ACTION_REQUIRED"
}
```

The resulting state is internally inconsistent:

- The same verification ID was previously `VERIFIED` with a future validity date of February 4, 2027.
- No new identity-verification attempt was initiated.
- The same record later became `DENIED` without an invalidation reason or remediation path.
- The use-case verification is `ACTION_REQUIRED`, not `DENIED`, while the application itself is already terminally `DENIED`.
- The organization was approved for CVP before the new Verification Portal workflow, but that prior approval was not retained or reconciled.

This appears to be part of a broader post-migration failure mode affecting previously approved CVP organizations. Potentially related user-visible reports include:

- #86867: approved CVP status unexpectedly changed to `In review`
- #89089: prior approval lost after the organization/portal migration and stuck `In review`
- #90316: prior CVP approval no longer recognized for an organization
- #87803: approved account reported as requiring CVP application
- #91566: active CVP status not honored by safeguards

Those reports describe downstream status/access symptoms. This report adds direct backend evidence of a same-object state regression in the Passport workflow.

Affected organization UUID:

```text
22d47750-f24c-4b0d-bbc7-5f7d534bea39
```

Relevant backend service:

```text
anthropic.passport.api.v1alpha.PassportVerificationPortalService
```

Relevant methods observed:

```text
GetPortalPassport
ListPrograms
PreviewProgramApplication
```

### What Should Happen?

A CVP identity-verification record that has already been successfully verified and has a future `validUntil` date should not silently transition from `PORTAL_VERIFICATION_STATE_VERIFIED` to `PORTAL_VERIFICATION_STATE_DENIED` without a new verification attempt, an explicit invalidation reason, or a remediation/appeal path.

If the record was intentionally revoked, the portal should expose a clear reason and provide a supported way to resolve or appeal the decision.

Previously approved CVP organizations migrated into the new Passport system should retain or correctly reconcile their prior CVP approval state.

### Error Messages/Logs

`ListPrograms` currently returns:

```json
{
"programs": [
{
"program": {
"slug": "cvp",
"displayName": "Cyber Verification Program",
"description": "Relaxed cyber safeguards for verified security researchers.",
"presentation": {
"unlocks": [
"Basic Pentesting, Red Teaming, Bug Bounty use cases"
],
"policyVersion": "1.0",
"reviewSlaDays": 2
}
},
"applicationStatus": "PROGRAM_APPLICATION_STATUS_DENIED"
}
]
}
```

`PreviewProgramApplication` currently returns:

```json
{
"unmetVerifications": [
{
"verificationType": "VERIFICATION_TYPE_USECASE_FORM_CYBER",
"programSlugs": ["cvp"],
"state": "PORTAL_VERIFICATION_STATE_ACTION_REQUIRED"
},
{
"verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
"verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
"programSlugs": ["cvp"],
"state": "PORTAL_VERIFICATION_STATE_DENIED",
"completedAt": "2026-08-31T20:13:01.987176Z"
}
],
"applicationStatus": "PROGRAM_APPLICATION_STATUS_DENIED"
}
```

Earlier capture of the same verification ID:

```json
{
"verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
"verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
"programSlugs": ["cvp"],
"state": "PORTAL_VERIFICATION_STATE_VERIFIED",
"validUntil": "2027-02-04T00:00:00Z"
}
```

### Steps to Reproduce

1. Use an organization that was previously approved for CVP and later migrated into the new Verification Portal / Passport workflow.
2. Complete the new cyber identity-verification process.
3. Observe the CVP verification state through the Verification Portal backend. In this case, the IDV record was initially returned as `PORTAL_VERIFICATION_STATE_VERIFIED` with `validUntil: 2027-02-04T00:00:00Z`.
4. Wait for the CVP application review state to change.
5. Query or open the CVP program page again so the portal calls `PassportVerificationPortalService/PreviewProgramApplication`.
6. Observe that the exact same `verificationId` is now returned as `PORTAL_VERIFICATION_STATE_DENIED` despite no new identity-verification attempt.
7. Observe that the overall application becomes `PROGRAM_APPLICATION_STATUS_DENIED`.
8. Observe that `VERIFICATION_TYPE_USECASE_FORM_CYBER` remains `PORTAL_VERIFICATION_STATE_ACTION_REQUIRED` rather than denied.

The regression is:

```text
same verificationId

VERIFIED
validUntil = 2027-02-04

↓

DENIED
completedAt = 2026-08-31
```

### Claude Model

Not sure / Multiple models; the defect is in the account-level Passport backend.

### Is this a regression?

Yes. The organization was previously approved, and the same IDV record was previously `VERIFIED`.

### Last Working Version

Not version-specific; the verified state existed before the Passport state transition.

### Claude Code Version

2.1.258 (current repository release at filing time: 2.1.259)

### Platform

Other: Anthropic Verification Portal / Passport backend

### Operating System

macOS

### Terminal/Shell

Other: zsh

### Additional Information

The exact verification ID and organization UUID are included so Anthropic can trace the backend state transition and migration history. The portal currently exposes no invalidation reason, remediation flow, or appeal path, and support has not provided an effective resolution.

Start by tracing PassportVerificationPortalService, especially GetPortalPassport, ListPrograms, and PreviewProgramApplication, and compare the migration history for the affected organization and verification ID. There are no repository files or tests named in the report, so first identify the state-transition and reconciliation code. Done means preserving a valid prior CVP verification or exposing an explicit revocation reason and remediation path without inconsistent application states.

索引モデルが issue の本文から書いたものです。