[OPS] Add token expiry warning mechanism (defense in depth)

[artcava]

Overview

Add a secondary safety mechanism that proactively warns 15 days before the LinkedIn refresh_token expires (365-day TTL). This acts as a fallback in case the auto-refresh function (#58) itself fails silently over multiple months.

Depends on: #58

Tasks

• When LinkedInTokenRefresherFunction successfully stores a new refresh_token, tag the Key Vault secret with the expiry date:

var secret = new KeyVaultSecret("LinkedInRefreshToken", newRefreshToken);
secret.Properties.ExpiresOn = DateTimeOffset.UtcNow.AddDays(365);
await secretClient.SetSecretAsync(secret);

• Create a new TimerTrigger function LinkedInTokenExpiryWarningFunction that runs weekly (0 0 9 * * 1) and:
  • Reads the ExpiresOn property of LinkedInRefreshToken from Key Vault
  • If expiry is within 15 days: logs LogWarning with message "LinkedIn refresh token expires in {days} days. Manual re-authorization required."
• The warning log triggers the existing alert rule from [OPS] Add Application Insights alert for LinkedIn token refresh failures #59 (severityLevel >= 3)

Acceptance Criteria

• Warning log appears in Application Insights when refresh token is within 15 days of expiry
• No warning when token is healthy
• Alert email received when warning is triggered

Notes

• This is a defense-in-depth measure — under normal operation (monthly auto-refresh working correctly) this function should never fire a warning
• Weekly check is sufficient given the 15-day warning window

References

• Analysis document — Section 5, Step 7

[github-actions]

👋 Thanks for opening this issue! A maintainer will review it soon and label it as approved if it can proceed to development.

[artcava]

Deferred

This issue is blocked and deferred until the LinkedIn token refresh strategy is unblocked.

The expiry warning mechanism tracks the ExpiresOn property of LinkedInRefreshToken in Key Vault — a secret that is only written by LinkedInTokenRefresherFunction (#58). Since the entire refresh chain (#56 → #57 → #58) is blocked pending availability of a valid refresh_token, this defense-in-depth measure has no foundation to build on yet.

See #56 for the full reasoning behind this deferral decision. This issue will be re-evaluated once #56, #57, #58, and #59 are unblocked.