Split Pub/Sub SDK into core and server gems

[umair-ably]

Implements the PubSub package split (PDR-091b) for the Ruby SDK, mirroring ably/ably-js#2293.

• New public package: ably-pubsub-server (server/), allowing Pub/Sub connections to explicitly declare they are server-side for realtime classification and MAU billing. Ruby is a server-only SDK under PDR-091b2, so there is no device gem. Factory functions are the only recommended entry points:
  • Ably::PubSub::Server.create_http_client(...)
  • Ably::PubSub::Server.create_realtime_client(...)
• Shared core: the implementation moves to ably-pubsub-core (core/), for internal/shared usage and not intended as a public API. The ably-common submodule moves with it.
• Agent stamping: the factories append the versionless side-declaring agent entry ably-pubsub-server (a pure flag, matching its Register the cross-SDK per-side Pub/Sub agents ably-common#361 registration — the ably-ruby/x.y.z entry beside it carries the version) via a new additive :agents client option. Caller entries are preserved; the side entry wins a collision on its own identifier. The -server suffix is what MAU classification reads, so specs assert it loudly.
• Lockstep versioning: core and server are both at 2.0.0, with the server gem pinning core to the exact version.
• The old ably gemspec is removed: the ably gem enters its 1-year maintenance window from a maintenance branch, not from here.

Unit suite green (1250 examples), sandbox acceptance smoke-tested, both gems build.

🤖 Generated with Claude Code

[paddybyers]

Given that there's no device variant, why move everything into core ?

[umair-ably]

CI triage:

• Fixed: connection_spec.rb agent-param spec used a single-digit version regex (\d.\d.\d), which current runner Rubies (e.g. 3.3.11) no longer match. Pre-existing brittleness, exposed on the 3.2/3.3 jobs.
• Pre-existing, not this branch: spec/acceptance/rest/presence_spec.rb:95 and :110 (presence GET filtered by client_id/connection_id) fail identically on main against sandbox — verified locally on a clean main worktree. Sandbox appears to no longer filter presence GET by those params; this needs investigating separately from this PR.

Everything else in the matrix is green (all unit jobs pass on every Ruby/protocol combination).

🤖 Generated with Claude Code

[umair-ably]

Given that there's no device variant, why move everything into core ?

@paddybyers https://ably.atlassian.net/wiki/spaces/product/pages/5348425729/PDR-091b2+Per-SDK+rollout+plan+v2#Support-window-for-existing-packages implies there's always a new core?

my own pov... I think the symmetry between packages is a good enough reason to keep as is, also create_http_client literally just calls the old Ably::Rest::Client.new under the hood. This old constructor needs to live somewhere, and keeping it in the same server package defeats the purpose of the new package obfuscating the old constructors (and preventing them from leaking in the public api)