Feature request: auto-update plugins on CLI startup via marketplace flag

## Summary

When a marketplace defines plugins, there is no way to signal that installed plugins should be kept up to date automatically. Users must manually run `copilot plugin update ` to get the latest version, which means teams shipping plugin updates have no guarantee consumers are on the current version.

## Proposal

Add an optional `autoUpdate` flag at the marketplace level in `marketplace.json`:

```json
{
"name": "my-org",
"metadata": {
"autoUpdate": true
},
"plugins": [...]
}
```

When `autoUpdate` is `true`, the CLI would check for plugin updates on startup (or periodically, e.g. once per day) and pull the latest for all installed plugins from that marketplace.

### Why marketplace-level rather than per-plugin?

- Simpler mental model — org admins opt in once for all their plugins
- Avoids inconsistent states where some plugins are stale and others are fresh
- Marketplace owners are already the trust boundary for plugin distribution

### Considerations

- **Startup latency**: A background check + async pull would avoid blocking the CLI. Could also be throttled to once per 24h with a local timestamp cache.
- **Opt-in**: This should be opt-in (default `false`) so existing marketplaces are unaffected.
- **Offline/CI**: Should gracefully no-op if the network is unavailable.

## Use case

We maintain an internal org marketplace with skills that evolve frequently (e.g., Confluence page generators, ticket readiness checks). When we ship an update, we currently have to Slack the team and ask everyone to manually run the update command. An auto-update flag would remove that friction entirely.

## Alternatives considered

- Shell profile hooks (`~/.zshrc`) — brittle, not portable, hard to enforce across a team
- Cron jobs — requires per-machine setup, easy to forget
- `copilot plugin update --all` on startup — would work but is less granular than marketplace-level control