Organized and formatted 69 articles from 'uncategorised' folder: - Added assets - Updated formatting - Moved each article to the correct category in the parent doc

[mrdavidorok]

• Added assets
• Updated formatting
• Moved each article to the correct category in the parent doc

Description

Provide a brief overview of what this documentation update is about. Explain what sections or topics are being added or revised.

Linear ticket and magic word Fixes DEVR-997

Type of change

• Typo fix
• New feature
• Enhancement to current docs
• Removed outdated references
• Update assets

Writing & Tone

• Use a neutral, instructional tone — avoid “I”, “we”, or “you should”.
• All titles and headers must follow Title Case.
• Avoid question-based titles and “How to…” phrasing.
• Keep titles concise for SEO; avoid long or vague titles.
• Use numbered bullet points for step-by-step instructions.
• Avoid vague transitions like “Next” or “After that” — use clear numbered steps.
• Do not use numbers in headings (e.g., ## 1. Check Settings is incorrect).

Code & Formatting

• Use backticks () for inline code like User.providerData`.
• Do not bold inline code or full code sentences.
• Use fenced code blocks with correct language tags (e.g., json, jsx, bash).
• Avoid combining bold and code formatting unnecessarily.

Admonitions (Notes, Warnings, Tips)

• Use proper admonition syntax: :::note, :::tip, :::warning, etc.
• Do not use “Pro Tip” in titles — the :::tip block already implies it.
• Avoid bolding entire sentences — only bold keywords or labels when needed.
• Do not add empty square brackets [] to admonition titles.

Linking

• Bold linked keywords in context .
• Never hyperlink vague words like “here” or “this document”.
• Use relative links for internal docs (e.g., /integrations/firebase/...).
• When referencing deployment, link directly to the mobile deployment doc.

Structure & Consistency

• Follow this structure: Introduction → Prerequisites → Steps → Notes → Resources.
• Match structure, tone, and formatting with existing FlutterFlow docs.
• Format prerequisites using the standard :::info[Prerequisites] block.
• Avoid repeating “in FlutterFlow” when it’s already implied.
• Use consistent bullet and heading formatting across all articles.

File Naming & SEO

• Do not use “issues” or “troubleshooting” in folder or slug names.
• Use descriptive, action-based slugs (e.g., /fix-push-notification-permissions).
• Slugs should be short, lowercase, and hyphenated.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.