docs: add example for --workspace_status_command

[shivanshjais22]

This PR adds a simple, self-contained example demonstrating how to use
--workspace_status_command in the Bazel user manual.

It includes:

• A small workspace status script example
• Sample output explanation
• A minimal genrule showing how to consume volatile status values during a build

This addresses the request in issue #17163 to make the documentation clearer
and easier for new users to understand.

Following the suggestion to proceed without formal assignment.
Fixes #17163

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

The pull request adds an example for --workspace_status_command to the user manual. While adding an example is a great improvement, the current implementation has some issues with markdown formatting and clarity that could confuse users. I've provided a suggestion to restructure the example for better readability and correctness.

[gemini-code-assist]

The example for --workspace_status_command has several issues that make it confusing and will cause rendering problems:

1. Markdown Syntax Error: There is a missing closing ```` for the code block, which will cause the rest of the document to be rendered as code.
2. Incorrect Content in Code Block: The sh code block contains user instructions (Make the script executable:) and a genrule definition (which is Python/Starlark syntax), neither of which are part of the shell script itself.
3. Confusing Structure: The example mixes file content, shell commands, and build rule definitions without clear separation or explanation of how they relate. For instance, the bazel build command appears before the genrule it's supposed to build.

I've suggested a rewrite that structures the example as a clear, step-by-step guide and fixes the formatting issues.

#### Example

The following example shows how `--workspace_status_command` can be used
to generate build metadata and consume it during a build.

First, create a workspace status script named `status.sh`:

```sh
#!/usr/bin/env sh
echo "BUILD_USER $(whoami)"
echo "BUILD_TIMESTAMP $(date +%s)"

Next, make the script executable:

chmod +x status.sh

Then, create a BUILD file with a genrule that consumes the status information. The stamp = 1 attribute is required for the rule to see the status files.

genrule(
    name = "gen_metadata",
    outs = ["metadata.txt"],
    cmd = "cat bazel-out/volatile-status.txt > $@",
    stamp = 1,
)

Finally, run the build, pointing to your script with the --workspace_status_command flag:

bazel build //:gen_metadata --workspace_status_command=./status.sh