velero: docs: Add STRIDE threat model

[Ralthos]

This is a document, not an implementation. #939 says not to start the plugin, and there is no
plugin code here: no index.tsx, no components, no package.json. It is a security assessment
of the system a plugin would sit on, put up now so the posture can be argued with before anyone
writes a component rather than retrofitted afterwards.

It follows the same shape as the threat models already in this repo (#883, #885, #888, #1208):
the OWASP four-question framework with STRIDE, an evidence-confidence label on every claim, a
qualitative risk method, a response register, and maintenance triggers.

What it found

Almost all of the risk belongs to Velero rather than to anything a plugin would invent, which is
the useful part: it constrains the design before the design exists.

DownloadRequest with target.kind: BackupContents causes the controller to sign a ten minute
object store URL (pkg/persistence/object_store.go:642, :96). The controller runs no
authorization check on whoever created the request; it reconciles any DownloadRequest that
exists (pkg/controller/download_request_controller.go:229). The URL is then fetched with an
ordinary GET carrying no Kubernetes credentials. Backups include Secrets unless an operator
excluded them, and exclusion is an explicit flag
(site/content/docs/main/resource-filtering.md:185).

So create on downloadrequests in the Velero namespace is closer to cluster-wide secret read
than its name suggests. That is Velero's behaviour and predates any plugin. It matters here
because a download control in a details view makes it routine, and because the plugin's install
documentation is where an operator will form their idea of what Velero namespace access implies.

Restore is the other one: creating the CR causes Velero to create the objects in a backup with
its own credentials, and those objects can include RoleBindings and ServiceAccounts.

The rest of the register covers irreversible backup deletion, actions addressed to the wrong
cluster in a multi-cluster selection, a health dashboard rendering "could not check" as green,
attribution, and the shared renderer context.

On confidence

Every claim carries Verified, Plausible or Open. The mechanisms above are Verified against
source and cited by line. The escalations they imply are Plausible, not Verified: nothing
here was executed against a multi-tenant cluster with a restricted subject, and the document
says so in its scope section rather than leaving it to be discovered.

I would rather have this argued with than agreed to. The four open questions at the end are the
parts I think a maintainer has to decide, particularly whether signed URLs should be fetched by
the browser at all, and whether restore belongs in a first release.