devcontainer-lock.json: feature lockfile not produced or honored

## Gap

The spec defines \`devcontainer-lock.json\` for reproducible feature resolution: each feature's resolved digest is recorded so subsequent runs pin to the same content. We have content-addressed caching (\`feature/disk_store.go\`) but no lockfile write/read.

## Expected

- On \`Up\`, after feature resolution, write \`/devcontainer-lock.json\` with each feature's \`ref\` → \`resolvedRef\` (digest).
- On subsequent \`Up\`, prefer the lockfile entry over re-resolving the mutable tag.
- Refresh policy: opt-in flag (e.g. \`UpOptions.RefreshFeatures\`) re-resolves and overwrites.

## Notes

Lower priority for DAP (it pins via pre-baked images), but expected by general spec consumers and the upstream CLI ecosystem.

Start by tracing the Up feature-resolution flow and the content-addressed cache in feature/disk_store.go. Identify where UpOptions can carry RefreshFeatures and where configDir is available. Done means Up writes and reads devcontainer-lock.json entries mapping ref to resolvedRef, while refresh re-resolves and overwrites them.

Written by the indexing model from the issue text.