docs: evaluate a deploy token for subtree export

**AI-generated draft — not reviewed by John**

## Context

The downstream needs to export the unsquashed `site-specific/` subtree to
`ORINOCO-Lite/con-site-specific` after an accepted website change reaches
`main`.

The proposed workflow uses the existing `orinoco-lite-curation-review` GitHub
App to mint a short-lived token limited to the destination repository. An
alternative is to authenticate with a dedicated deploy token stored as an
Actions secret in this repository.

GitHub does not provide a GitLab-style “deploy token.” In this issue, **deploy
token** means a fine-grained personal access token owned by a dedicated
automation or machine account, restricted to `ORINOCO-Lite/con-site-specific`
with only the repository-content permission required to push.

## Alternative design

1. Create or select a dedicated automation identity.
2. Issue a fine-grained token restricted to
`ORINOCO-Lite/con-site-specific`.
3. Grant only `Contents: Read and write`.
4. Store it in `con/dev-centerforopenneuroscience.org` as an Actions secret,
such as `CON_SITE_SPECIFIC_PUSH_TOKEN`.
5. Use it only in the default-branch subtree-export workflow.
6. Keep the existing fast-forward check before every push and fail on
divergence.

## Advantages

- Simpler workflow: no GitHub App token-minting step or App private key is
required.
- Easier initial setup when a suitable automation account and
fine-grained-token policy already exist.
- Independent of the curation-review App’s installation and permission
lifecycle.
- Directly usable by ordinary Git and straightforward to test.
- Repository and permission scope can be substantially narrower than a classic
personal access token.

## Disadvantages

- The credential is a long-lived bearer secret rather than a short-lived
installation token.
- Rotation and expiration must be monitored and handled manually.
- Ownership is tied to an account; suspension, removal from an organization,
SSO changes, or account-policy changes can stop exports.
- Organization approval may be required for a fine-grained token spanning the
`con` and `ORINOCO-Lite` boundary.
- Audit attribution is associated with the automation account rather than a
purpose-specific GitHub App installation.
- A compromised token remains usable until expiration or revocation.
- It introduces another automation identity and credential lifecycle to
maintain.
- Repository or organization policy may prohibit or restrict personal access
tokens, just as the destination currently prohibits deploy keys.

## Comparison with the GitHub App strategy

The GitHub App requires its private key to be stored in the website repository,
but each workflow run exchanges that key for a short-lived token restricted to
the named destination repository. This provides stronger runtime token scoping
and clearer App attribution.

The deploy-token alternative removes the token-exchange machinery, but places
more responsibility on account ownership, expiration, rotation, and manual
revocation.

## Decision criteria

Prefer the deploy-token design only if:

- `ORINOCO-Lite` permits the fine-grained token and its automation identity;
- the token can be restricted to the one destination repository and
`Contents: write`;
- a named maintainer owns rotation and recovery; and
- the simpler setup is worth retaining a long-lived bearer credential.

Otherwise, retain the short-lived GitHub App token design.

## Acceptance criteria if selected

- The secret is unavailable to pull-request workflows and is used only after
changes reach the default branch.
- The workflow verifies that the destination `main` is an ancestor of the
split commit.
- The workflow never force-pushes.
- Token scope, owner, expiration, and rotation procedure are documented
without recording the token itself.
- A failed or expired credential produces a clear, non-destructive workflow
failure.

Start by locating the existing default-branch subtree-export workflow and reviewing how it currently uses the orinoco-lite-curation-review GitHub App. Compare that flow with the proposed fine-grained token, checking repository scope, secret availability, fast-forward and non-force-push safeguards, and credential failure handling. Done means a documented decision and, if selected, documented ownership, expiration, rotation, and recovery procedures.

Written by the indexing model from the issue text.