Warn users when Store SDK lifecycle hooks may access secret-like project files

## Summary

After the 0.9.0 release, I have been trying Workshop across several projects.

First of all, Workshop has been a very pleasant and powerful developer experience. The ability to define a reproducible development environment, launch it quickly, and use the same project files from both the host and the isolated workshop environment is extremely useful. I would like to see more developers adopt it.

While using Workshop in real projects, I noticed one area where a small security hardening step could improve the trust model around SDKs: warning users when Store SDK lifecycle hooks may run with access to secret-like files in the mounted project directory.

This is not intended to suggest that Workshop’s host isolation model is broken. Rather, I think it is a visibility improvement around project data exposure.

## Background

The Workshop security documentation already explains that, by design, all SDKs in a workshop can access any data inside it, while their host capabilities are limited by confinement. It also recommends not storing sensitive data within workshops, and suggests assuming that no SDK is free from security concerns if users want to be cautious.

Reference: https://ubuntu.com/workshop/docs/security/

That guidance makes sense. However, in real development workflows, it is common to keep local test or development secrets in the project directory and exclude them from Git.

Examples include:

* `.env` / `.env.local`
* `.npmrc` / `.pypirc`
* `.aws/credentials`
* `.kube/config`
* `.docker/config.json`
* `terraform.tfvars` / `terraform.tfstate`
* local private keys such as `id_rsa` or `id_ed25519`

This is especially relevant because Workshop SDK lifecycle hooks can run after the project is mounted at `/project`.

## Proposal

As a first low-cost hardening step, Workshop could warn when both of the following are true:

1. The workshop uses one or more SDKs from the SDK Store.
2. The project directory contains common secret-like local files.

The warning would be:

* non-blocking
* path-only
* not reading file contents
* based on common high-confidence secret-like filenames
* integrated with the existing `workshop warnings` flow

The exact list of detected files can be conservative at first to avoid false positives. For example, it could focus on environment files, package registry credentials, cloud credentials, kube/docker auth files, Terraform variables/state, and local private keys.

## Where the warning could be emitted

A small implementation could hook into the launch/refresh flow after SDK manifests are resolved and before lifecycle hook tasks are executed.

Conceptually:

```text
LaunchManifests / RefreshManifests resolves SDKs
-> check whether Store SDKs are present
-> scan the project path for high-confidence secret-like file paths
-> if both are true, add a non-blocking state warning
-> continue launch/refresh normally
```

This could reuse the existing warning mechanism so the normal CLI flow remains unchanged.

## Local prototype result

I tested this approach locally with a small prototype.

Example:

```text
$ workshop launch
"dev" launched
WARNING: There are 1 new warnings. See "workshop warnings".

$ workshop warnings
last-occurrence: today at 02:49 UTC
warning: |
Store SDKs "go" may run lifecycle hooks with access to project files in
"/home/user/project". Potentially sensitive local files were found:
".env", ".npmrc". Review SDK trust before continuing.
```

The operation remains non-blocking. The warning only makes the trust boundary visible.

I am not opening this as a PR yet, but I can share the fork/commit history.

https://github.com/canonical/workshop/compare/main...shizuku198411:workshop:feat/sdk-project-exposure-warning

## Notes

This warning would not prevent users from using SDKs, and it would not attempt to inspect secret contents.

Longer-term improvements could include SDK preflight review, first-use consent, SDK revision/digest pinning, and project secret masking. However, a non-blocking warning seems like a small first step that fits the existing warning mechanism.

I would really appreciate hearing the Workshop maintainers’ and community’s thoughts on whether this kind of warning would be useful, and how it should fit into Workshop’s trust model.