Pre-baked feature match ignores options #154

Gap

markAlreadyInstalled / bakedFeature treat a feature in the base image's devcontainer.metadata label as satisfying a request when its id and version match (feature.Matches), plus, since #153, its recorded artifact. The options the request asks for are never compared with the ones the image was built with.

So a request for ghcr.io/x/b:1 with {"flavor": "spicy"} is satisfied by a base image that installed b with its defaults. The requested options are silently not applied. This has been true for declared features since the pre-baked fast path was added. With #151 it also applies to features pulled in through dependsOn, which the DAP review flagged there (dap-finding 3903).

Why it isn't a one-line fix

• The label doesn't record the options a feature was installed with.
• It doesn't carry the feature's option schema either, so the defaults can't be applied to the request before comparing. Without that, {} and {"flavor": "plain"} would compare unequal.
• Labels written before options are recorded can't be checked at all. Rejecting them would make every existing pre-baked image reinstall its features on the next Up. Accepting them keeps today's behaviour.

Proposed

1. Record each installed feature's applied options (after defaults) in its label entry, alongside the resolvedRef and dependsOn it already carries.
2. In the baked match, apply the feature's defaults to the request and compare it with the recorded options. A baked feature whose options differ is fetched and installed as usual.
3. Labels that don't record options keep the current permissive match. Under StrictFeatureVersionMatch they are rejected.

Follow-up to #151 / #153.