[DEV] Implement KeyVaultService abstraction

[artcava]

Overview

Implement a IKeyVaultService abstraction and its concrete implementation wrapping Azure.Security.KeyVault.Secrets.SecretClient. This service will be consumed by LinkedInAuthService and LinkedInTokenRefresherFunction and is designed to be mockable in unit tests.

Depends on: #54

Tasks

• Add NuGet packages to src/XPoster.csproj:
  • Azure.Security.KeyVault.Secrets
  • Azure.Identity
• Create src/Abstraction/IKeyVaultService.cs:

public interface IKeyVaultService
{
    Task<string> GetSecretAsync(string secretName);
    Task SetSecretAsync(string secretName, string value);
}

• Create src/Services/KeyVaultService.cs using DefaultAzureCredential (works both locally with az login and in Azure with Managed Identity)
• Register in Program.cs as Singleton:

builder.Services.AddSingleton<IKeyVaultService, KeyVaultService>();

• Write unit tests with mocked IKeyVaultService in tests/XPoster.Tests/Services/KeyVaultServiceTests.cs

Acceptance Criteria

• IKeyVaultService is fully mockable
• Local development works via az login (no hardcoded credentials)
• Azure deployment works via Managed Identity
• Unit tests pass

References

• Analysis document — Section 5, Step 5

[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]

Deferral Decision

After reviewing the current implementation state (post #55), this issue is being deferred until the LinkedIn token auto-refresh feature is actively scheduled.

Reasoning

IKeyVaultService was designed to serve two consumers:

• GetSecretAsync — reading secrets at runtime (e.g. LINKEDIN_ACCESS_TOKEN, LINKEDIN_CLIENT_ID, LINKEDIN_CLIENT_SECRET)
• SetSecretAsync — writing updated secrets after a token refresh cycle

With the Azure Key Vault References introduced in #55, the runtime reads are already handled transparently by the Azure Functions host — the Key Vault reference is resolved before any C# code executes, so InSender continues to work without any direct dependency on IKeyVaultService.

The SetSecretAsync path is only needed by LinkedInTokenRefresherFunction, which is blocked until a viable token refresh strategy is confirmed. Since LinkedIn refresh tokens are currently unavailable in this setup, there is no active consumer for the write path.

Implementing now would produce:

• Dead code (SetSecretAsync with no caller)
• Unit tests for an abstraction not yet exercised by a real use case
• Risk of designing the interface incorrectly before the actual consumer's requirements are clear

Recommended next action

Re-evaluate this issue when the LinkedIn token refresh strategy is unblocked (alternative approaches: scheduled manual renewal reminder, webhook-based rotation, or a different OAuth flow). At that point, the interface requirements will be well-defined and the implementation can be scoped correctly.