improve storage documentation clarity and fix inconsistencies

[evnchn]

Motivation

Addresses feedback from discussion #5717 where users reported significant confusion with storage documentation, including:

• Critical table inconsistency about tab storage persistence across restarts
• Unclear terminology ("needs client connection")
• Missing guidance for multi-instance deployments
• Undocumented storage behavior in native mode
• Confusion about when/how storage initialization occurs

Implementation

Fixed Critical Inconsistencies:

• Corrected storage comparison table: tab storage "across server restarts" now shows "No*" with footnote explaining it's only "Yes" with Redis
• Added footnote explaining "needs client connection" means awaiting client.connected() before accessing storage

Added Storage Initialization Documentation:

• Documented when and how each storage type is initialized
• Explained multi-tab behavior and data sharing between tabs
• Documented tab duplication behavior (copies initially, then independent)

Enhanced Native Mode Documentation:

• Documented that automatic port scanning via find_open_port() is already implemented and used by default (scans ports 8000-8999)
• Critical addition: Documented storage path conflicts when running multiple instances of the same file from the same location
• Provided solutions: separate NICEGUI_STORAGE_PATH per instance or Redis

Key Distinction Clarified:
Port conflicts are automatically handled in native mode, but storage path conflicts require manual configuration.

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
• If this PR addresses a security issue, it has been coordinated via the security advisory process. (N/A)
• Pytests have been added (or are not necessary). (Documentation only)
• Documentation has been added (or is not necessary). (This IS the documentation)

Final notes

This is also written by Claude. Rough readthrough by me.

[evnchn]

Though the PR description may be a bit slack, I screened the content of this PR quite carefully. Should not have technical inaccuracies.

[phifuh]

@evnchn

A) Where is the storage located?
If I remember correctly, it’s a dictionary saved somewhere, but I’m wondering why the “tab” storage type can be persisted with Redis while the browser/user storage cannot.

B) In discussion thread #5719 I asked whether port scanning runs when native=False. Is it active in that configuration?

C) Even when we run an app in native mode, the app remains accessible in the browser.
Does this mean the browser storage for the user (the “browser” storage) and the technical “open‑tab” storage can retain persistent data across native‑window restarts? I’m not sure whether this behavior is intentional or caused by having the reload argument set to true.

D) It would be helpful to link directly to the "section_configuration_deployment.py" documentation whenever native/Redis is mentioned.
Perhaps a brief standalone subsection could be added there.

E) What does “Write only before response” mean exactly, and why does it apply only to the browser storage and not to the tab storage?

F) Are the tab storage and browser storage the same kind of dictionary?
If so, why doesn’t tab storage require serializable data?

G) A colleague pointed out that “Needs serializable data” and “Needs storage_secret” are implementation concerns, whereas the other options are more about choosing the appropriate storage type.
It feels like mixing concerns, but it might still make sense to keep them together in the same table.

[falkoschindler]

@evnchn What's that status of this PR? Looks like there are many open questions. Should we postpone?