FileSystemProvider should expose original discovery failures after initialization

Enhancement

With FileSystemProvider, a configured module can fail to import while the provider continues loading the remaining components and the server still starts. discover_and_import() returns those failures in DiscoveryResult.failed_files, but after provider initialization there is no supported way for the application to inspect that original discovery result.

This matters for applications that need to distinguish an intentionally empty/conditional provider from a server that booted successfully but failed to load a configured capability. Re-running discovery is not a safe workaround because module imports can have top-level side effects and execute twice.

Concrete use case: a tool module raises during import because required configuration is missing; the server boots and list_tools() omits that tool, but the application cannot inspect the provider's original discovery failure through a public API.

Expected: applications can observe whether the provider's original discovery had failures, so they can choose their own tolerant or strict policy without re-importing modules.

Actual: the structured failure result is transient during provider loading; afterward only warnings/private implementation state remain.