[fix][broker] Prevent partition expansion from inheriting delayed-delivery bucket state

[void-ptr974]

Fixes #26178

Motivation

When increasing partitions, Pulsar copies durable subscription properties from
partition-0 to new partitions.

Bucket delayed delivery stores cursor-local snapshot metadata as
#pulsar.internal.delayed.bucket*. Copying that state makes a new partition
recover delayed-message indexes that belong to partition-0, which can result in
incorrect delayed-delivery state and invalid replay attempts.

Modifications

Filter #pulsar.internal.* properties before creating subscriptions on new
partitions. User-defined subscription properties are still copied.

Existing cursor-property and stats exposure is unchanged.

Verifying this change

• Added partition-expansion coverage for internal cursor properties.
• Added bucket delayed-delivery coverage that activates the new partition's
  tracker and verifies it recovers zero delayed messages.
• ./gradlew --no-daemon --console=plain :pulsar-broker:test --tests org.apache.pulsar.broker.admin.IncrementPartitionsTest --tests org.apache.pulsar.broker.service.persistent.BucketDelayedDeliveryTest
• ./gradlew --no-daemon --console=plain :pulsar-broker:checkstyleMain :pulsar-broker:checkstyleTest

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

[Denovo1998]

Filtering here addresses partition expansion, but since #26159, the Admin getSubscriptionProperties endpoint returns raw cursor properties, including #pulsar.internal.*, while updateSubscriptionProperties delegates to ManagedCursorImpl#setCursorProperties, which rejects maps containing that prefix. Consequently, a GET → modify → PUT cycle can fail once bucket state exists. Should we note a follow-up to restore the user/internal property boundary for instance, by exposing filtered user properties through the Admin API while keeping raw cursor properties accessible only to broker internals?

[void-ptr974]

Thanks for pointing this out. I agree this is a separate issue around the public API boundary. Since it is outside the partition-expansion fix in this PR, I would prefer to track it in a follow-up issue/PR.