Set unpublishable: true on PublishedChange by construction to simplify handleMaxRevs predicate

[AlexVelezLl]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Current behavior

In serverSync.js, handleMaxRevs uses findLastIndex to compute two values for deciding whether to set unpublished_changes = true on a channel:

• lastChannelEditIndex — the last publishable change, filtered (among other conditions) with c.type !== CHANGE_TYPES.PUBLISHED
• lastPublishIndex — the last publish change, matched with c.type === CHANGE_TYPES.PUBLISHED

The predicate for lastChannelEditIndex already includes !c.unpublishable, making the explicit c.type !== CHANGE_TYPES.PUBLISHED check partially redundant: if PublishedChange always set unpublishable: true, the type check would be unnecessary.

Desired behavior

PublishedChange and PublishedNextChange set unpublishable: true by construction (in its constructor in changes.js), so the c.type !== CHANGE_TYPES.PUBLISHED guard in handleMaxRevs can be removed. The !c.unpublishable check alone is sufficient to exclude publish changes from lastChannelEditIndex.

This makes the semantics self-contained in the change object — callers don't need to know the type mapping — and reduces the risk of future change types being accidentally treated as publishable.

Acceptance Criteria

• PublishedChange constructor in changes.js sets unpublishable: true unconditionally
• The c.type !== CHANGE_TYPES.PUBLISHED condition is removed from the lastChannelEditIndex predicate in handleMaxRevs (serverSync.js)
• Existing tests for PublishedChange in changes.spec.js pass (updated if needed to assert unpublishable: true)
• unpublished_changes continues to be set correctly after a publish event (no regression)

References

Follow-up to #5844 (comment)

AI usage

This issue was drafted with Claude Code assistance from session context and code review.