docs: restore 11 pages that are still live on the docs site

[theojin]

Change Description

Restores 11 documents that were removed by the recent cleanup commits but are still published and reachable on the live documentation site. Every restored file is verified to return HTTP 200 today. Without this, those URLs become 404s on the next publish.

Each file is restored byte-for-byte from the commit immediately before its deletion. No content was edited.

1. Section landing pages (4)

The site redirects each section root to its overview page:

Section root	Redirects to (301)
/docs/application/dotnet	/docs/application/dotnet/overview
/docs/application/native	/docs/application/native/overview
/docs/application/web	/docs/application/web/overview
/docs/application/flutter	/docs/application/flutter/overview

So removing these does not just drop one page — it breaks the entry point to the entire section. Following the ".NET" entry in the navigation would land on a 404, even though the 24,000+ pages underneath remain reachable by direct URL.

These pages are not listed as children in any TOC, which is most likely why they were classified as unlisted content. Being unlisted is what makes them landing pages, not what makes them obsolete.

Also restored for the same reason: extensions/tizenx/overview.md.

2. Pages not specific to Mobile or Wearable (6)

These appear to have been swept up by the profile cleanup even though they are not profile-specific:

• application/dotnet/guides/notification/attach-panel.md
• application/native/guides/text-input/capi-ui-gesture.md
• application/native/reference/security-privileges-legacy.md
• application/web/guides/applications/web-widget.md
• application/web/guides/multimedia/camera.md
• application/web/reference/security-privileges-legacy.md

How these 11 were identified

Two independent signals were cross-checked against the 433 markdown files deleted in 63609d51d, edca393fb, d0e188132, 26c727a41, 25cf65689 and 532a525fe:

1. Path-to-URL mapping compared against the published sitemap (34,274 URLs).
2. The publishing pipeline's own record. The generated TOC data stores the upstream source path for every published page, so this needs no URL guessing.

Signal 2 turned out to be a strict subset of signal 1. The four extra entries in signal 1 are exactly the overview sections, which have no TOC entry for signal 2 to see — a self-consistent explanation rather than a discrepancy. All 11 were then confirmed individually with a live request.

The opposite direction was checked as well: a 20-file sample of the deletions classified as safe all returned 404 (legacy design/*, tizen-studio-0/*, and EFL Mobile/Wearable content). The other 422 deletions look correct and are intentionally left untouched — this PR does not revert those commits, it only restores individual files.

Dead links repaired (second commit)

Checking the restored pages against the live site turned up three links whose targets are not published and therefore 404, not just the one originally flagged. All three are fixed in the second commit, and each was verified with a request before and after.

Page	Link	Why it 404s	Fix
dotnet/overview	../api/dotnet-standard-limitations.md	file exists in the repo but is not published	drop the link, keep the caveat
native/overview	../api/overview.md	unpublished hub page	remove the bullet
web/overview	../guides/security/security.md	file does not exist	link the three published Security pages

Two of the three point at api/overview.md-style hub pages that live in this repository but never reach the site, so the links work in the GitHub file view and break once published. There is no published landing page for either the .NET or the native API reference — the native reference exists only as versioned group pages, and no other published guide links to it — so there was nothing to retarget to. The links are removed and the surrounding prose is kept intact.

The third is different: the target file is genuinely gone, but the content is not. In the site TOC, Security is a group node with an empty path — a category with no page of its own — while its three child pages are published. The dead link is replaced with that same shape:

- Security
  - [Secure Key Management](../guides/security/secure-key.md)
  - [TEE Communication](../guides/security/tee-client.md)
  - [Privacy-related Permissions](../guides/security/privacy-related-permissions.md)

This keeps the category visible in the guide list instead of dropping it, and every link resolves. Happy to collapse it back to a single bullet if you would rather keep the list flat.

All 16 internal links across the 11 restored files now resolve to published pages.

To rule out the obvious suspicion, the first two targets were checked against history: they are not casualties of the recent cleanup. dotnet-standard-limitations.md has not been modified since 2018 and native/api/overview.md since 2025-09, and both files are present in the tree today, so there is no earlier revision to restore. They are simply outside the current publishing scope — the .NET API section is generated from TizenFX, and the native API section walks version folders only — which is why the pages never appear on the site.

One note for follow-up, outside this PR: dotnet-standard-limitations.md is not stale legacy content. It documents real constraints that still apply (redirected standard output, Process.GetProcesses() throwing), and that information appears nowhere on the published site. Whether it should be brought into the published set is a docs-ownership decision rather than a link fix, so nothing here changes it.

Bugs Fixed

N/A

API Changes

N/A

[TizenDocsBot]

Can one of the admins verify this patch?

[TizenDocsBot]

Can one of the admins verify this patch?

[mindol]

Looks good to me.
고생하셨습니다.