Fix API token status messages

[lntutor]

What this PR does / why we need it:

The API Token tab now identifies the authenticated user when no token exists, reports token validity using the actual expiration date, and displays a warning for expired tokens. English and Spanish translations are updated together.

Which issue(s) this PR closes:

• Closes Fix messages in AccountPage API Token tab #943

Special notes for your reviewer:

Chromatic and label-copy checks cannot access fork secrets/permissions; those fork-only failures are expected.

Suggestions on how to test this:

1. View the API Token tab with no token and confirm the username appears.
2. Generate a valid token and confirm the expiration date is displayed.
3. Test an expired token and confirm the warning state.
4. Run the focused API-token component spec; all 12 tests pass locally.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Yes. It updates status and warning copy in the existing API Token tab; no mockup is required.

Is there a release notes or changelog update needed for this change?:

No separate release note is included.

Additional documentation:

No additional documentation is required.

Verification: focused Cypress component tests (12 passing), lint (four pre-existing unrelated warnings), production build, and diff check.

[lntutor]

Current head 7652f1a is mergeable, and I do not see any unresolved review threads or contributor-side follow-up remaining on the current PR state. This looks ready for maintainer review when someone has a chance.

[lntutor]

Merged current develop and resolved the additive changelog conflict on head 7652f1a19b199ed0f018179562601ceb0cec8ad5. Exact-head local verification: focused API-token component spec 12/12 passing, npm run lint passing with four pre-existing unrelated warnings, production build passing, and staged git diff --check passing.

[lntutor]

The fresh GitHub Actions runs for exact head 7652f1a19b199ed0f018179562601ceb0cec8ad5 are currently classified as action_required with no jobs, which is a maintainer-controlled fork workflow approval gate rather than a code failure. Could a maintainer approve the workflow run when convenient? The focused test, lint, build, and diff checks are already recorded above.