Add display scale param to public functions

[olejnjak]

Summary

In some situations like components with very tight layout it might be useful to test how it will look on various display scales, so it is good to be able to override displayScale from init in assert call.

In such cases as attached, every pixel counts

Author checklist

• updated changelog under Next section

[Copilot]

Pull Request Overview

This PR introduces an optional displayScale override to snapshot assertions, allowing tests to specify a custom display scale when rendering SwiftUI snapshots.

• Added a displayScale: CGFloat? = nil parameter to all public assertSnapshot variants
• Updated internal trait-building logic to prefer the override (scaleParam) over the stored displayScale
• Documented the new parameter in the CHANGELOG.md

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Sources/AckeeSnapshots/SnapshotTest.swift	Added displayScale parameter to public/assert methods and updated internal calls to apply it
CHANGELOG.md	Added entry for displayScale under Next and reorganized release notes

Comments suppressed due to low confidence (3)

Sources/AckeeSnapshots/SnapshotTest.swift:277

• [nitpick] The internal parameter name scaleParam is ambiguous alongside the displayScale property; consider renaming it to something like overrideDisplayScale for clarity.

displayScale scaleParam: CGFloat?,

Sources/AckeeSnapshots/SnapshotTest.swift:294

• New behavior for overriding displayScale should be covered by unit tests or snapshot tests to ensure the override is applied correctly in all layout variants.

(scaleParam ?? displayScale).map { .init(displayScale: $0) },

CHANGELOG.md:3

• [nitpick] The placeholder instruction still reads generically; consider clarifying or removing this line to match the rest of the formatted changelog.

please enter new entries in format, new entries on top