fix(docs-infra): redirect three removed pages instead of 404ing

`guide/http/security` and `reference/concepts` both still exist as content but
neither is routed, so each falls through to the 404 shell.

`guide/http/security` was navigable from November 2023 until #54365 removed its
entry in February 2024. #55029 then copied its XSRF sections into the security
guide, which already covered XSSI, and #55060 repointed the remaining links, so
it now redirects to `/best-practices/security`.

`reference/concepts` was added by #54365 and removed by #58694 in November
2024, leaving it navigable for nine months without a redirect. The same commit
also removed `guide/ngmodules`, the route its only card linked to, so both now
redirect to `/guide/ngmodules/overview`, alongside the four `guide/ngmodules/*`
paths already redirected there.

Both pages are removed, along with the Bazel package that existed only to build
the concepts page, and the stale `llms-list.md` entry for the HttpClient page.
The security guide takes its place in that list, so `llms-full.txt` keeps its
XSSI coverage and picks up CSP, Trusted Types and sanitization with it.

(cherry picked from commit 7da60d1920)

adev/src/app/routing/redirections.ts

@@ -163,4 +163,16 @@ export const REDIRECT_ROUTES: Route[] = [
     path: 'signal-forms',
     redirectTo: '/playground?templateId=4-signal-forms',
   },
+  {
+    path: 'guide/http/security',
+    redirectTo: '/best-practices/security',
+  },
+  {
+    path: 'reference/concepts',
+    redirectTo: '/guide/ngmodules/overview',
+  },
+  {
+    path: 'guide/ngmodules',
+    redirectTo: '/guide/ngmodules/overview',
+  },
 ];

adev/src/assets/BUILD.bazel

@@ -37,7 +37,6 @@ copy_to_directory(
         "//adev/src/content/introduction",
         "//adev/src/content/introduction/essentials",
         "//adev/src/content/reference",
-        "//adev/src/content/reference/concepts",
         "//adev/src/content/reference/configs",
         "//adev/src/content/reference/errors",
         "//adev/src/content/reference/errors:route-nav-items",

adev/src/content/guide/http/security.md

@@ -1,62 +0,0 @@
-# `HttpClient` security
-
-`HttpClient` includes built-in support for two common HTTP security mechanisms: XSSI protection and XSRF/CSRF protection.
-
-TIP: Also consider adopting a [Content Security Policy](https://developer.mozilla.org/docs/Web/HTTP/Headers/Content-Security-Policy) for your APIs.
-
-## XSSI protection
-
-Cross-Site Script Inclusion (XSSI) is a form of [Cross-Site Scripting](https://en.wikipedia.org/wiki/Cross-site_scripting) attack where an attacker loads JSON data from your API endpoints as `<script>`s on a page they control. Different JavaScript techniques can then be used to access this data.
-
-A common technique to prevent XSSI is to serve JSON responses with a "non-executable prefix", commonly `)]}',\n`. This prefix prevents the JSON response from being interpreted as valid executable JavaScript. When the API is loaded as data, the prefix can be stripped before JSON parsing.
-
-`HttpClient` automatically strips this XSSI prefix (if present) when parsing JSON from a response.
-
-## XSRF/CSRF protection
-
-[Cross-Site Request Forgery (XSRF or CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery) is an attack technique by which the attacker can trick an authenticated user into unknowingly executing actions on your website.
-
-`HttpClient` supports a [common mechanism](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token) used to prevent XSRF attacks. When performing HTTP requests, an interceptor reads a token from a cookie, by default `XSRF-TOKEN`, and sets it as an HTTP header, `X-XSRF-TOKEN`. Because only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.
-
-By default, an interceptor sends this header on all mutating requests (such as `POST`) to relative and same origin URLs, but not on `GET` or `HEAD` requests.
-
-<docs-callout helpful title="Why not protect GET requests?">
-CSRF protection is only needed for requests that can change state on the backend. By their nature, CSRF attacks cross domain boundaries, and the web's [same-origin policy](https://developer.mozilla.org/docs/Web/Security/Same-origin_policy) will prevent an attacking page from retrieving the results of authenticated `GET` requests.
-</docs-callout>
-
-To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called `XSRF-TOKEN` on either the page load or the first GET request. On subsequent requests the server can verify that the cookie matches the `X-XSRF-TOKEN` HTTP header, and therefore be sure that only code running on your domain could have sent the request. The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens. Set the token to a digest of your site's authentication cookie with a salt for added security.
-
-To prevent collisions in environments where multiple Angular apps share the same domain or subdomain, give each application a unique cookie name.
-
-<docs-callout important title="HttpClient supports only the client half of the XSRF protection scheme">
-  Your backend service must be configured to set the cookie for your page, and to verify that the header is present on all eligible requests. Failing to do so renders Angular's default protection ineffective.
-</docs-callout>
-
-### Configure custom cookie/header names
-
-If your backend service uses different names for the XSRF token cookie or header, use `withXsrfConfiguration` to override the defaults.
-
-Add it to the `provideHttpClient` call as follows:
-
-```ts
-export const appConfig: ApplicationConfig = {
-  providers: [
-    provideHttpClient(
-      withXsrfConfiguration({
-        cookieName: 'CUSTOM_XSRF_TOKEN',
-        headerName: 'X-Custom-Xsrf-Header',
-      }),
-    ),
-  ],
-};
-```
-
-### Disabling XSRF protection
-
-If the built-in XSRF protection mechanism doesn't work for your application, you can disable it using the `withNoXsrfProtection` feature:
-
-```ts
-export const appConfig: ApplicationConfig = {
-  providers: [provideHttpClient(withNoXsrfProtection())],
-};
-```

adev/src/content/reference/BUILD.bazel

@@ -15,7 +15,6 @@ generate_guides(
 js_library(
     name = "guide_files",
     srcs = glob(["**/*.md"]) + [
-        "//adev/src/content/reference/concepts:guide_files",
         "//adev/src/content/reference/configs:guide_files",
         "//adev/src/content/reference/errors:guide_files",
         "//adev/src/content/reference/errors:route-nav-items",

adev/src/content/reference/concepts/BUILD.bazel

@@ -1,16 +0,0 @@
-load("//adev/shared-docs:defaults.bzl", "js_library")
-load("//adev/shared-docs:index.bzl", "generate_guides")
-
-generate_guides(
-    name = "concepts",
-    srcs = glob([
-        "*.md",
-    ]),
-    visibility = ["//adev:__subpackages__"],
-)
-
-js_library(
-    name = "guide_files",
-    srcs = glob(["**/*.md"]),
-    visibility = ["//adev:__subpackages__"],
-)

adev/src/content/reference/concepts/overview.md

@@ -1,7 +0,0 @@
-# Concepts
-
-<docs-card-container>
-  <docs-card title="NgModules" link="Learn more" href="guide/ngmodules">
-    NgModules is a concept that commonly used in architecture v16 and earlier to help configure the injector and the compiler and help organize related things together.
-  </docs-card>
-</docs-card-container>

adev/src/context/llms-list.md

@@ -108,5 +108,5 @@ adev/src/content/guide/animations/migration.md
 adev/src/content/guide/zoneless.md
 adev/src/content/reference/roadmap.md
 adev/src/content/best-practices/update.md
-adev/src/content/guide/http/security.md
 adev/src/content/guide/i18n/overview.md
+adev/src/content/guide/security.md