Milestone: get and set for secrets, per provider

## Summary

Longer-term, let ultra read and write individual secrets through each provider, for example ultra get and ultra set , implemented optionally per secret backend. This is a future milestone, not immediate work.

## Why

ultra already knows how to locate a secret for an app: the prefix/app/NAME naming, the vault item, and so on. Exposing get and set would make ultra the single tool for managing secrets, not just injecting them. You could rotate a value, seed a new secret when adding a Config field, or inspect what is stored, without dropping down to each provider's own CLI.

It also closes the loop with the validate and lint drift checks. You find a missing or unreferenced key, then set or remove it from the same tool.

## Scope

Each secret provider, 1Password, AWS Secrets Manager, Vault, and any custom one, would implement get and set optionally. Providers that cannot or should not support writes simply do not. The SecretResolver interface would grow an optional capability, a separate reader/writer interface that is feature-detected, so existing resolvers keep working unchanged.

No files or tests are named. Start by reading the SecretResolver interface and tracing the CLI entry points for the proposed ultra get and ultra set commands, then inspect the 1Password, AWS Secrets Manager, Vault, and custom provider implementations. Done means providers can optionally expose read/write capabilities while existing resolvers continue working unchanged.

Written by the indexing model from the issue text.