build!: leave the gcs: crawler client to the fess-lib-gcs plugin

[marevol]

crawler/client.xml no longer declares gcsClient or maps gcs:.* to it. GcsClient and the gcs: URL handler stay in this library and still compile against the Google Cloud Storage SDK; what changes is that nothing here names the class, so the SDK is no longer needed to build the container.

Fess 15.9 stops shipping that SDK — around 17 MiB of jars for a protocol most installations never crawl — and moves it to the fess-lib-gcs plugin. The plugin registers the client through crawlerClientCreator, the way fess-crawler-playwright registers playwrightClient, so installing it restores gcs: crawling.

Why the declaration cannot stay here

Both failure modes were reproduced:

• Without the SDK — the webapp does not start. Lasta Di resolves the class named by a component while it parses the Di xml, not when the component is first used, so the failure lands at container init rather than at the first crawl:

  DiXmlParseFailureException at /components[1]/include[19]
  Caused by: java.lang.NoClassDefFoundError: com/google/cloud/NoCredentials
  SEVERE: Exception starting filter [lastaPrepareFilter]
  SEVERE: Context [] startup failed due to previous errors
  

  This is build!: move the GCS client into the fess-lib-gcs plugin fess#3424's CI, which builds Fess without the SDK against this library as it stands today.

• With the plugin installed. Both files declare gcsClient, the component key becomes ambiguous, and the first crawl gets TooManyRegistrationComponentException. Reproduced against a running Fess with a fake-gcs-server bucket.

Compatibility

Consumers of this library that relied on the gcs: mapping keep GcsClient itself and can register it in their own container.

Merge order

codelibs/fess#3424 has the matching change and stays red until this one is merged and its snapshot is published — the failure above is exactly what its Run Fess step hits.