feat: add multi-page editing and printing

[masonsxu]

Summary

• add multi-page editing so users can create and manage multiple independent pages
• update preview and printing so each page is rendered and printed as its own A4 page
• restore sample templates and add a multi-page resume sample

Closes #1

Scope

This PR focuses on the multi-page editing and printing workflow only.

It does not include any fork-specific Docker publishing workflow, personal image distribution, or deployment-related README changes.

Test plan

• Run bun run build
• Verify the diff only includes multi-page related changes in src/main.ts, src/samples.ts, src/style.css, and README.md
• Confirm no Dockerfile, workflow, or fork-specific deployment docs are included

[gemini-code-assist]

Code Review

This pull request introduces multi-page editing and printing support to the PrintFit application. Key changes include refactoring the state management to handle multiple pages, updating the UI to allow adding/removing pages, and refining the printing logic to ensure correct layout across multiple A4 sheets. Feedback suggests using the beforeprint event to ensure consistent layout when printing via browser menus and ensuring styles are applied to empty pages to maintain theme consistency.

[gemini-code-assist]

The current implementation of preparePrint is only triggered by the custom button or the Cmd+P shortcut. If a user initiates printing through the browser's native menu (e.g., File > Print), the is-printing class won't be added and the CSS transforms won't be cleared, leading to a broken layout in the print output.

Consider using the beforeprint event to handle these preparations globally, ensuring consistency regardless of how printing is started.

Suggested change

	function preparePrint(): void {
	document.body.classList.add('is-printing')
	// Remove inline styles for printing
	for (const state of pageStates) {
	state.page.style.transform = ''
	state.page.style.transformOrigin = ''
	}
	window.print()
	}
	window.addEventListener('beforeprint', () => {
	document.body.classList.add('is-printing')
	// Remove inline styles for printing
	for (const state of pageStates) {
	state.page.style.transform = ''
	state.page.style.transformOrigin = ''
	}
	})
	function preparePrint(): void {
	window.print()
	}

[masonsxu]

Thanks. I’m intentionally keeping print preparation inside preparePrint() instead of a global beforeprint handler. This app’s print flow depends on entering a controlled print state first; if printing is triggered from the browser’s default menu, the browser may print the whole page rather than the intended A4 preview area, which causes layout and style issues. So for now I prefer to keep printing scoped to the app’s explicit print flow.

[gemini-code-assist]

When a page is empty, the loop continues without calling applyStyles. This means that if the user changes the theme or other global styles, empty pages will not reflect these changes (e.g., an empty page might stay white while others turn dark in a 'Noir' theme).

Suggested change

	if (!markdown.trim()) {
	state.content.textContent = ''
	continue
	}
	if (!markdown.trim()) {
	state.content.textContent = ''
	applyStyles(state.page, settings, 16)
	continue
	}

[masonsxu]

Thanks. I’m keeping the current behavior for now. Applying page styles unconditionally to empty pages looks straightforward, but in this flow it may introduce side effects, so I’d rather leave it unchanged unless we confirm a concrete visual bug caused by empty pages not inheriting theme updates.