ci: wire lib/sdk/server-ai into release and publish workflows

[mattrmc1]

Summary

Wires lib/sdk/server-ai into the repo's release and publish plumbing. Release-please already tracks the module
(release-please-config.json + .release-please-manifest.json at 0.2.0) and has cut launchdarkly-java-server-sdk-ai-0.1.0
and -0.2.0 tags and GitHub Releases — but nothing was listening for the baton afterward, so .github/actions/full-release
(Publish → Publish Docs) has never run for the module.

Consequences today:

• com.launchdarkly:launchdarkly-java-server-sdk-ai has zero versions on Maven Central, despite the module README
  advertising the coordinate as published.
• https://launchdarkly.github.io/java-core/lib/sdk/server-ai/ returns 404; gh-pages contains
  lib/sdk/server, lib/shared/*, lib/java-server-sdk-otel, and lib/java-server-sdk-redis-store but no server-ai.
• There was no manual escape hatch either — the module was missing from both workflow_dispatch choice lists.

This is config-only. No build or source changes are needed: lib/sdk/server-ai/build.gradle already applies
maven-publish, signing, and nexusPublishing, sets archivesBaseName = 'launchdarkly-java-server-sdk-ai', declares
full POM metadata, and produces withJavadocJar() / withSourcesJar() (both excluding
com.launchdarkly.sdk.server.ai.internal).

What changed

.github/workflows/release-please.yml:

• New job output package-server-sdk-ai-released from steps.release.outputs['lib/sdk/server-ai--release_created'].
• New release-server-sdk-ai job, identical in shape to the existing per-module release jobs, gated on that output and
  calling ./.github/actions/full-release with workspace_path: lib/sdk/server-ai, dry_run: false, prerelease: false.

.github/workflows/manual-publish.yml and .github/workflows/manual-publish-docs.yml:

• Added lib/sdk/server-ai to the workspace_path choice lists so the module can be published — and, importantly, so its
  Javadoc can be pushed to gh-pages — on demand.

Follow-up (not in this PR)

1. Backfill the Javadoc site immediately after merge: dispatch Publish Docs with workspace_path: lib/sdk/server-ai,
   dry_run: false. publish-pages writes to output_path: lib/sdk/server-ai, and gh-pages docs are overwritten in place
   rather than versioned, so this is safe to run from main and makes the GitHub Pages URL work without publishing a jar.
2. First Central release should be a fresh version, not a back-publish of 0.2.0. main carries unreleased changes on
   top of the 0.2.0 tag — including a breaking one (fix!: Make AgentGraph traversal topological #199, fix!: Make AgentGraph traversal topological) — while
   gradle.properties still reads version=0.2.0. Merging this PR and letting the open release-please PR cut the next
   version gets the artifact published from a matching tree.
3. Docs links become referenceable once released:
   https://launchdarkly.github.io/java-core/lib/sdk/server-ai/ (Javadoc, the analogue of the .NET
   launchdarkly.github.io/dotnet-core/pkgs/sdk/server-ai/ page) and
   https://central.sonatype.com/artifact/com.launchdarkly/launchdarkly-java-server-sdk-ai (package page, the analogue of
   the NuGet listing).

Verification

• release-please workflow parses and the new job appears in the run graph (skipped when no server-ai release is cut).
• Publish Docs dispatch offers lib/sdk/server-ai and, after running, gh-pages contains
  lib/sdk/server-ai/index.html and the Pages URL renders the LDAIClient Javadoc.
• After the next release, https://repo1.maven.org/maven2/com/launchdarkly/launchdarkly-java-server-sdk-ai/maven-metadata.xml
  lists the version (allow ~30 min for Central sync) and a scratch Gradle project resolves the coordinate.
• Published sources/javadoc jars exclude com.launchdarkly.sdk.server.ai.internal — the build already enforces this, but
  it's worth confirming on the first artifacts ever produced for real.

---

Note

^{Cursor Bugbot is generating a summary for commit eab1c4d. Configure here.}