Clarifies the intended lifetime of stdio MCP server processes.

Motivation and Context

The stdio transport documentation says that clients launch servers as subprocesses, but it does not currently spell out the intended lifetime boundary for those subprocesses. That leaves room for clients or server authors to treat a single task or conversation as the natural process boundary.

This adds an informational SEP and corresponding documentation clarifications stating that a stdio server process should generally live for approximately the lifetime of the host application instance that launched it, and should be expected to serve multiple conversations over that lifetime.

The change also updates the client best-practices guidance so task or conversation completion is not presented as the default disconnect signal for stdio servers.

How Has This Been Tested?

Documentation-only change.

• Reviewed the updated stdio transport wording and client best-practices guidance together for consistency.
• Ran SEP generation checks to confirm the new draft SEP does not affect generated SEP docs unexpectedly.
• Ran formatting checks on the touched documentation files.

Breaking Changes

None. This is a documentation-only clarification and does not change the wire protocol, schema, or runtime behavior.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This PR intentionally keeps the clarification narrow:

• stdio server lifetime should be tied to the host application instance, not to an individual task, thread, or conversation
• stdio servers should expect to handle multiple conversations over a single process lifetime
• hosts may still explicitly start, stop, or restart servers for application-level reasons such as disablement, configuration changes, crash recovery, or shutdown