Revise sidebar structure, labels, and frontmatter for usability and discoverability (#449)

* Initial plan

* docs: revise sidebar structure, labels, and add missing frontmatter tags

- Merge Basic Configuration + Properties into single Configuration category
- Rename Actions→Keywords & Actions, GUI→Web/GUI, API→REST API, CLI→CLI/Terminal, DB→Database
- Rename Project Setup Guides→Project Setup, Did You Know→Advanced Topics
- Reorder Advanced Topics items by topic group (locators, browser control, grid, testing, integrations)
- Reorder Best Practices in logical learning progression
- Move Soft vs Hard Assertions to second position under Validations
- Add tags frontmatter to 11 Best Practices pages
- Fix vague sidebar_labels: Types→Property Types, List→Properties Reference, Examples→Common Examples, Builder→Request Builder, Parsing→Response Parsing, Validations→Response Validations, Actions→Database Actions

Agent-Logs-Url: https://github.com/ShaftHQ/shafthq.github.io/sessions/c86ecf35-b460-4c85-91ad-b7ce57c18bc5

Co-authored-by: MohabMohie <19201898+MohabMohie@users.noreply.github.com>

---------

Signed-off-by: Mohab Mohie <Mohab.MohieElDeen@outlook.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: MohabMohie <19201898+MohabMohie@users.noreply.github.com>
Co-authored-by: Mohab Mohie <Mohab.MohieElDeen@outlook.com>

Author: Copilot

docs/Best_Practices/Architecture.md

@@ -4,6 +4,7 @@ title: "Test Automation Architecture"
 sidebar_label: Architecture
 description: "Understand common test automation architectures and where SHAFT Engine fits in the technology stack."
 keywords: [SHAFT, test automation architecture, framework layers, Selenium, Appium, REST Assured, architecture diagram]
+tags: [best-practices, architecture, framework-design]
 ---
 
 A well-designed test automation architecture separates concerns into layers, making tests easier to write, maintain, and scale. This page explains the common layers and where SHAFT Engine fits.

docs/Best_Practices/BDD_Style_Reports.md

@@ -4,6 +4,7 @@ title: "BDD-Style Reports with Allure Annotations"
 sidebar_label: BDD-Style Reports
 description: "Use Allure annotations to generate business-readable BDD-style reports without Cucumber — simpler setup, better maintainability."
 keywords: [SHAFT, Allure annotations, BDD reports, business-readable, Epic, Feature, Story, Description, Cucumber alternative]
+tags: [best-practices, bdd, allure, reporting]
 ---
 
 Many teams adopt Cucumber or similar BDD frameworks to produce **business-readable reports**. However, you can achieve the same report output using **Allure annotations** directly in your Java tests — without the overhead of maintaining `.feature` files, step definitions, and glue code.

docs/Best_Practices/CI_CD_Integration.md

@@ -4,6 +4,7 @@ title: "Running Tests in CI/CD Pipelines"
 sidebar_label: CI/CD Integration
 description: "How to run SHAFT Engine tests in CI/CD pipelines — configuring properties, headless execution, and pipeline integration tips."
 keywords: [SHAFT, CI/CD, continuous integration, pipeline, Jenkins, GitHub Actions, headless, Maven, properties]
+tags: [best-practices, cicd, pipeline, jenkins, github-actions]
 ---
 
 Running your SHAFT tests in a CI/CD pipeline is straightforward. SHAFT's [property system](../Properties/PropertyTypes) lets you override any configuration from the command line, making it easy to adapt tests for unattended pipeline execution.

docs/Best_Practices/Cross_Platform_Strategy.md

@@ -4,6 +4,7 @@ title: "Cross-Platform Strategy: Android and iOS"
 sidebar_label: Cross-Platform Strategy
 description: "When to combine Android and iOS tests in one project vs. separate projects, and how to handle platform-specific locators with SHAFT Engine."
 keywords: [SHAFT, cross-platform, Android, iOS, mobile testing, platform strategy, locator strategy, Appium]
+tags: [best-practices, mobile, cross-platform, android, ios, appium]
 ---
 
 One of the most common questions in mobile test automation is: **should Android and iOS tests live in the same project or in separate projects?** The answer depends on how similar the apps are.

docs/Best_Practices/Element_Identification.md

@@ -4,6 +4,7 @@ title: "Element Identification Best Practices"
 sidebar_label: Element Identification
 description: "Best practices for element identification in SHAFT Engine — By objects, dynamic locators, cross-platform locators, and why to avoid @FindBy."
 keywords: [SHAFT, element identification, By locator, dynamic locator, cross-platform, Android, iOS, FindBy]
+tags: [best-practices, locators, elements, selenium, xpath, css]
 ---
 
 Choosing the right element identification strategy is critical to building stable, maintainable tests. SHAFT Engine encourages the use of standard Selenium `By` objects and its own [Locator Builder](../Keywords/GUI/didYouKnow/Shaft_Locator_Builder) over alternatives like `@FindBy`.

docs/Best_Practices/Fluent_Design.md

@@ -4,6 +4,7 @@ title: "Fluent Design: Chaining Actions and Validations"
 sidebar_label: Fluent Design
 description: "Learn how to use SHAFT Engine's fluent API to chain actions and validations for readable, maintainable test code."
 keywords: [SHAFT, fluent design, method chaining, fluent API, readable tests, test design, chaining actions]
+tags: [best-practices, fluent-api, chaining, test-design]
 ---
 
 SHAFT Engine provides a **fluent API** that lets you chain actions and validations in a single, readable statement. Instead of writing one action per line, you can express an entire test step as a flowing sentence.

docs/Best_Practices/Solution_Design.md

@@ -4,6 +4,7 @@ title: "Test Automation Solution Design Patterns"
 sidebar_label: Solution Design
 description: "Compare test automation design patterns — Page Object Model, fluent design, anonymous classes, inheritance, and base classes — with SHAFT Engine examples."
 keywords: [SHAFT, design patterns, Page Object Model, POM, fluent design, base class, inheritance, test architecture]
+tags: [best-practices, design-patterns, page-object-model, architecture]
 ---
 
 How you design your test automation solution determines its readability, maintainability, and scalability. This page compares the most common patterns and shows how each works with SHAFT Engine.

docs/Best_Practices/Test_Artifacts.md

@@ -4,6 +4,7 @@ title: "Test Artifacts and Report Paths"
 sidebar_label: Test Artifacts
 description: "Where to find SHAFT Engine test artifacts — Allure reports, execution summaries, and how to publish them from CI/CD pipelines."
 keywords: [SHAFT, test artifacts, allure report, execution summary, CI/CD artifacts, report paths, archive]
+tags: [best-practices, reporting, artifacts, cicd]
 ---
 
 After a test run, SHAFT generates several artifacts that you can use for debugging, reporting, and auditing. This page explains where to find them and how to publish them from your CI/CD pipeline.

docs/Best_Practices/Test_Structure.md

@@ -4,6 +4,7 @@ title: "Test Structure: Cases vs. Scenarios"
 sidebar_label: Test Structure
 description: "Understand the difference between isolated test cases and dependent test scenarios, and why you should avoid using priority to order tests."
 keywords: [SHAFT, test structure, test cases, test scenarios, test priority, dependsOnMethods, isolated tests, TestNG]
+tags: [best-practices, test-structure, testng, junit5]
 ---
 
 How you structure your tests has a major impact on reliability, maintainability, and debugging speed. This page covers the two main approaches — **isolated test cases** and **dependent test scenarios** — and explains why you should avoid using `priority` to control execution order.

docs/Best_Practices/Testing_Pyramid.md

@@ -4,6 +4,7 @@ title: "The Testing Pyramid and Automation Strategy"
 sidebar_label: Testing Pyramid
 description: "Understand the testing pyramid, the role of each testing level, and how to build an effective test automation strategy with SHAFT Engine."
 keywords: [SHAFT, testing pyramid, automation strategy, unit tests, integration tests, E2E tests, API tests, UI tests]
+tags: [best-practices, strategy, testing-pyramid, automation]
 ---
 
 The **testing pyramid** is a foundational concept in test automation strategy. It guides how many tests you should have at each level and where your automation investment delivers the most value.