Fix redirects not written or deployed for isolated builds

[cotti]

Why

Redirects defined in _redirects.yml for docs-builder's own docs (and any other isolated/per-docset build) were silently discarded. IsolatedBuildService.Build called GenerateAll with the discard operator (_ = await), so the GenerationResult.Redirects map was thrown away and redirects.json was never written to disk. And even if it had been written, no workflow step ever pushed it to the redirect store the preview environment already serves from.

What

• IsolatedBuildService.Build: captures the GenerateAll result and writes redirects.json to the output directory, resolving each redirect's relative file paths to absolute URL paths using the configured --path-prefix
• assembler deploy update-redirects: gains a --no-delete flag that skips the KVS reconciliation delete pass — only PUTs the new entries. This is required for per-docset deploys, which only know about their own redirects and must not wipe other repos' entries from a shared KVS
• docs-preview-local.yml: adds a "Deploy redirects to CloudFront KVS" step after the S3 upload, running on pushes to main only, that invokes assembler deploy update-redirects --no-delete preview

How

The URL resolution in IsolatedBuildService.ToAbsoluteUrl mirrors FileNavigationLeaf.DetermineUrl: strips .md, strips trailing /index, and treats a bare index path as the path-prefix root. Cross-repo redirects (containing ://) are skipped since the isolated build has no cross-link resolver to follow them.

Known limitation: with --no-delete there is no reconciliation, so redirects removed from _redirects.yml will linger in the KVS. A scoped reconciliation (deleting only keys under this docset's path prefix) is a reasonable follow-up.

[reakaleek]

Do we have redirects in our preview environment?

[cotti]

Good question — I went and checked the infra to be sure. The preview environment does already have the full redirect-serving setup:

• The redirects key-value store for the preview environment exists (verified it's live), it's just empty — nothing has ever populated it.
• The CloudFront function that does the KVS lookup and issues the 301s is already associated with the default cache behavior of the preview distribution.
• The OIDC deployer role this repo's workflows assume already has write permission on that store.

So the only missing piece was exactly what this PR adds: producing redirects.json from the isolated build and pushing it. The key format also lines up — on push to main the build runs with the /​elastic/docs-builder/tree/main path prefix, which matches the URIs the CloudFront function looks up.

One known limitation worth flagging: since the deploy uses --no-delete (to avoid touching other repos' entries in the shared store), redirects removed from _redirects.yml will linger in the store. A scoped reconciliation — deleting only keys under this docset's path prefix — would be a reasonable follow-up.