docs(resize): document concurrency and ingress defaults

[CorieW]

The Resize Images kit README documents the move to Gen2 but omits its concurrency and ingress differences from the extension. Document these defaults in the existing "The trigger is 2nd gen" section.

Changes

• Explain the kit's default concurrency of 80 per instance versus 1 for the Gen1 extension, including shared CPU/memory and the full-CPU requirement.
• Document ALLOW_ALL for the kit versus ALLOW_INTERNAL_ONLY for the extension, and distinguish ingress from IAM invocation permissions.
• Link to the Firebase concurrency and Cloud Functions ingress documentation.

Validation

• Confirmed live deployments in corie-testing: the Gen2 kit reports concurrency 80 and ALLOW_ALL; the Gen1 extension reports ALLOW_INTERNAL_ONLY and has Gen1's single-invocation behavior.
• Prettier 2.8.8 check and git diff --check passed. Documentation only; no runtime tests needed.
• The worktree's pre-commit tooling could not run, so its Prettier formatting step was run directly and the commit used HUSKY=0.

[gemini-code-assist]

Code Review

This pull request updates the README.md for the storage-resize-images kit to document the default concurrency and ingress settings. The feedback suggests adding a warning about the risk of Out of Memory (OOM) errors and CPU throttling due to the high default concurrency limit (80 concurrent invocations) on resource-intensive image resizing tasks.

[gemini-code-assist]

Since image resizing is highly CPU and memory intensive, allowing the default concurrency of up to 80 concurrent invocations on a single instance (especially with the default 1GB memory) is highly likely to cause Out of Memory (OOM) crashes or severe CPU throttling. It is important to explicitly warn users about this risk and recommend reducing the concurrency limit or increasing the allocated resources.

Suggested change

	- **Concurrency:** with the default CPU allocation, each kit instance can handle
	up to **80 concurrent invocations**, compared with **1** for the 1st gen
	extension. Concurrent image resizes share the instance's CPU and memory. See
	[Firebase's concurrency documentation](https://firebase.google.com/docs/functions/manage-functions#allow_concurrent_requests)
	for configuration options and the requirement for at least one full CPU.
	- **Concurrency:** with the default CPU allocation, each kit instance can handle
	up to **80 concurrent invocations**, compared with **1** for the 1st gen
	extension. Concurrent image resizes share the instance's CPU and memory. Because image resizing is highly resource-intensive, running multiple concurrent resizes on a single instance can easily lead to Out of Memory (OOM) errors or severe CPU throttling. It is highly recommended to tune this setting (e.g., reducing concurrency or increasing memory/CPU) based on your expected load. See
	[Firebase's concurrency documentation](https://firebase.google.com/docs/functions/manage-functions#allow_concurrent_requests)
	for configuration options and the requirement for at least one full CPU.