fix(examples): add missing prerequisites and KWOK stage-fast in setup.sh

[mesutoezdil]

Customer Summary

Users who run setup.sh and then follow the next-step instructions will hit errors if helmfile or helm-diff is not installed. The script also did not apply the KWOK stage-fast manifest, which causes pods to stay stuck after helmfile sync.

Summary

Two fixes to setup.sh, both found while reviewing the script after #4.

First, helmfile and helm-diff were added to the pre-flight checks. The summary section tells users to run HELMFILE_ENV=local helmfile sync, but the script never checked that those tools were present.

Second, stage-fast.yaml was added to the KWOK install step. Without it, KWOK nodes do not simulate fast pod-lifecycle transitions and pods appear stuck in Pending after helmfile sync.

For the Reviewer

Both changes are additive and follow the existing patterns in the file. The KWOK manifest URL uses the same pinned version (v0.7.0) already in the file.

For QA

Run setup.sh without helmfile installed and confirm it exits early with a clear error message.

Run setup.sh on a clean machine and confirm pods reach Running after helmfile sync.

Issues

Related to #4

Checklist

• I am familiar with the Contributing Guidelines.
• I have signed off my commits for Developer Certificate of Origin (DCO) compliance.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

JIRA: NO-REF
NVBug: none

[mesutoezdil]

@kristinapathak @sbaum1994 following up on your comments in #4, here are two fixes found while reviewing setup.sh.

[kristinapathak]

hi @mesutoezdil, thanks for the contribution! We're currently pushing changes to this repo from gitlab. We can't directly merge this PR, but soon you'll see a commit to main with these changes and your co-authorship. This will change in the near future to allow for direct merges in github.

[mesutoezdil]

@kristinapathak thanks for the quick turnaround on #6. One question before I spend more time on contributions: since changes flow through GitLab and cannot be merged directly on GitHub, what is the recommended workflow for external contributors? Is opening GitHub PRs the right path, or is there a better way to submit patches so they land reliably with attribution?
I'm asking because I'm wondering whether I should invest my time or devote my energy to other projects.

[kristinapathak]

@mesutoezdil, this is the correct workflow for now. Our plan is to get this fixed so we can merge directly from github in the next few weeks, but I don't have an exact target date at this time.

[mesutoezdil]

@kristinapathak thanks! one small suggestion: a short note in CONTRIBUTING.md explaining that GitHub PRs flow through GitLab and attribution is preserved via co-author would save future contributors the confusion that came up in #4 and #6.
I will hold off on new PRs until the pipeline on github is fixed.