Add command to generate types without deploying

[SajeelHussain]

Adds a standalone sst types command that regenerates sst-env.d.ts from the currently deployed state of a stage, without requiring sst dev or sst deploy.

Closes #6872

This reuses the existing GetCompleted() logic for reading deployed state and types.Generate(), the same function used by sst deploy to generate type definitions.

Verified end-to-end by:

1. Deploying an app.
2. Deleting sst-env.d.ts.
3. Running sst types.
4. Confirming the file was regenerated identically.

[SajeelHussain]

@vimtor one open question on error handling I'd like your call on before this is final.

What happens today when sst types runs on a stage that hasn't been deployed yet?

The command reads the deployed state via p.GetCompleted() (same as sst shell / sst tunnel). On a never-deployed stage, Pull() returns provider.ErrStateNotFound, and since that error isn't in the Transform table in cmd/sst/mosaic/errors/errors.go, the user just sees:

✕  Unexpected error occurred. Please run with --print-logs or check .sst/log/sst.log if available.

It fails cleanly (exit 1, no state touched), but the message isn't helpful, the real reason is "this stage hasn't been deployed."

Worth noting: sst shell and sst tunnel have the exact same behavior, since they also use GetCompleted and don't map ErrStateNotFound. So this isn't specific to types, it's a shared gap. (For contrast, deploy/diff go through p.Run, which converts ErrStateNotFound → ErrStageNotFound, and that one is mapped to "Stage not found".)

How would you like to handle it? A few options:

1. Leave as-is — match shell/tunnel exactly. Ship types with identical behavior and treat the message as a separate issue.
2. Map it centrally — add exact(provider.ErrStateNotFound, "...") to the Transform table in errors.go. One line, and it improves shell/tunnel too. Something like: "This stage hasn't been deployed yet. Run sst deploy first."

I'm leaning toward (2) since it fixes the root cause the conventional way and benefits the other commands, but I didn't want to expand the scope of this PR without checking. Happy to do whichever you prefer.