Fix: --tools/--toolsets ignored in streamable-HTTP env-var mode (#376)

[sebin]

Summary

Fixes #376.

When the server was launched via env vars (TRANSPORT_MODE / TRANSPORT_HOST / TRANSPORT_PORT / MCP_ENDPOINT) instead of the explicit streamable-http subcommand, main() called runHTTPServer directly without ever calling rootCmd.Execute(). cobra therefore never parsed os.Args[1:], so both --tools and --toolsets always fell back to their declared defaults ("" and "all"), regardless of what the operator passed on the command line. The HCP-Terraform toolset was silently enabled in full whenever TFE_TOKEN was present, even when the operator asked for a smaller set.

Change

• Move the env-var-driven HTTP-mode detection inside runDefaultCommand (the default Run of rootCmd), so cobra's Execute() always runs first and the --tools / --toolsets persistent flags are populated before getToolsetsFromCmd reads them.
• Collapse main() to a plain rootCmd.Execute().
• The explicit `streamable-http` subcommand path is unchanged.
• No exported API changes; no behavior change for stdio mode.

Diff is +18 / -18.

Verification

```bash
TRANSPORT_MODE=streamable-http MCP_SESSION_MODE=stateless TFE_TOKEN=x \
./terraform-mcp-server --tools=list_workspaces,get_workspace_details &

curl -s -X POST http://localhost:8080/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
| grep -oE '"name":"[a-zA-Z_]+"' | sort -u | wc -l
```

• Before: 43 (full catalog).
• After: 2 (only the requested tools).

Existing test suite passes:

```
$ go test ./...
ok ... 571 passed in 10 packages
```

Test plan

• All existing tests pass (`go test ./...`).
• Manual repro from --tools and --toolsets flags silently ignored in streamable-HTTP env-var mode #376 returns the requested 2 tools instead of 43.
• `stdio` subcommand unchanged — still honours `--tools` / `--toolsets`.
• Explicit `streamable-http` subcommand unchanged — still honours `--tools` / `--toolsets`.

Notes for reviewers

I did not add a new test because `runDefaultCommand` blocks on the server until SIGINT and the existing tests don't have a harness for that path. Happy to add one (e.g. extracting the toolset-selection block into a helper that takes a stub for the server-run function) if maintainers want it.

[sebin]

Heads-up on a side effect of the structural change that I should have called out in the PR body — the four-line logger setup at the top of the old main() was removed:

logFile, _ := rootCmd.PersistentFlags().GetString("log-file")
logLevel := getLogLevel(rootCmd)
logFormat := getLogFormat(rootCmd)
logger, err := initLogger(logFile, logLevel, logFormat)

These reads ran before rootCmd.Execute() and therefore had the same defect as the --tools / --toolsets reads — they always returned the declared defaults ("", "info", "text") regardless of what the operator passed as --log-file=… / --log-level=debug / --log-format=json. The resulting logger was only consumed by the env-var-driven HTTP branch; every other code path (stdioCmd, streamableHTTPCmd, runDefaultCommand) constructs its own logger inside its Run after cobra has parsed flags.

After the fix, the env-var-driven HTTP branch lives inside runDefaultCommand, which already calls initLogger(…) with correctly-parsed flag values. The top-of-main() block became both redundant and incorrect, so it was removed. CLI log flags now actually take effect in the env-var-driven path — a small bonus fix from the same structural change.

[jaylonmcshan19-x]

Hey @sebin Thanks for finding the issue and providing the fix :)
One final ask: Can you include a regression test? Given the bug silently exposed the whole catalog when someone asked for a subset, I'd be nice to have something locking the behavior down.