Add a warning/confirmation when using BUILD-available secrets for local builds

[falahat]

Description

When a user builds with Local Builds and has BUILD-available secrets, these might be left as artifacts. For example, if they write the value of that secret to one of their statically-compiled pages, that build artifact might be left on their temporary folders. We want to confirm the secret-reading behavior with users for local builds. If using non-interactive mode, it requires a flag to allow reading secrets.

Scenarios Tested

Run a local build without a secret. Shouldn't ask for confirmation.
Run a local build with the secret. It should ask for confirmation.

Do the same but with non-interactive mode and with/without the flag to allow local build secrets.

[gemini-code-assist]

Code Review

This pull request introduces a security confirmation prompt and a bypass flag (--allow-local-build-secrets) for local App Hosting builds that utilize build-available secrets. This ensures users are aware that sensitive values might be left in local artifacts. I have identified a few issues: a mismatch in an error message within the test suite, a missing property in the Options interface that will cause a TypeScript compilation error, and an opportunity to reduce code nesting in accordance with the repository style guide.

[falahat]

I manually tested this, the CLI warning showed up as expected

? Your build includes secrets that are available to the build environment. Using secrets in local builds may leave sensitive values in local artifacts/temporary files. Do you want to
continue? (y/N)

[falahat]

I manually tested this both interactively and non-interactively. The deployment was blocked when using build secrets if I did not confirm or use the flag.