fix: prevent panic in writePage when partition runs out of pages at a namespace boundary

[jgangemi]

The bug

writePage slices the partition buffer at pageOffset:pageOffset+PageSize before checking pageNum against totalPages:

func writePage(partition *[]byte, startPageNum int, seqNum uint32, entries []*entry, totalPages int) (int, error) {
	pageNum := startPageNum
	pageOffset := pageNum * PageSize
	page := (*partition)[pageOffset : pageOffset+PageSize]

The mid-item overflow path (startNewPage, called once a page is already partially filled) already guards against running out of pages and returns a clean not enough pages error. This initial slice, taken before any entry has been placed on the page, has no equivalent guard.

writePage gives every namespace its own fresh page — it never packs a new namespace's entries into a previous namespace's leftover slots — so GenerateNVS needs at least as many pages as there are distinct namespaces. When that requirement already exactly exhausts the partition, starting the next namespace calls writePage with startPageNum == totalPages, and the initial slice reads straight past the end of the partition.

On a stock 6-page (0x6000) NVS partition this reproduces as:

panic: runtime error: slice bounds out of range [:28672] with capacity 24576

(6 * 4096 = 24576 is the partition's actual capacity; the slice tries to read to 7 * 4096 = 28672.)

The fix

Add the same totalPages guard to the initial slice that startNewPage already has, so this case returns the existing not enough pages error instead of panicking:

if pageNum >= totalPages {
	return 0, fmt.Errorf("not enough pages: need at least %d pages", pageNum+1)
}

Repro / regression test

Added TestGenerateNVSInsufficientPagesAtNamespaceBoundaryReturnsErrorNotPanic in pkg/nvs/nvs_test.go: 6 single-key namespaces exactly fill a 6-page partition (one page per namespace), then a 7th brand-new namespace is added, pushing the running page index to exactly 6 == totalPages before any entry is placed. Before the fix this panics; after, it returns a clean error.

Mutation-checked locally: reverting just the added guard reproduces the exact slice bounds out of range [:28672] with capacity 24576 panic on this new test; restoring the guard is byte-identical to this diff and the suite is green again.

How this was found

Found via a downstream tool (esp_nvs_set/esp_nvs_delete operations) hitting this panic against a real ESP32 with a 0x6000 NVS partition when writing a namespace that pushed the generated image exactly to the partition's page limit.