chore: adopt the mechanical portfolio Python standards (dependabot uv, exclude-newer, workflow hardening)

[pofallon]

Step 1 ("free, mechanical, no design review needed") from the portfolio Python Project Standard. No behavior change to the CLI, the web service, or the release process.

1. Dependabot pip → uv

This repo resolves from the committed uv.lock, and the pip ecosystem does not update that file — it would bump pyproject.toml and leave the lock, which is what CI and the Docker build actually install from, untouched.

This is the one item in the batch that was a live defect rather than a style gap.

2. [tool.uv] exclude-newer = "7 days"

The resolver-side twin of the Dependabot cooldown this repo already configures. Without it, a plain uv sync still pulls a just-published transitive dependency that Dependabot would have waited 7 days on.

Verified uv 0.12.5 accepts the relative form rather than assuming it: uv lock resolves it to a concrete cutoff and records exclude-newer-span = "P7D". No package version moved — the lock diff is 4 added lines recording the option.

3. permissions: + concurrency: on all ten workflows

Before: 4/10 had top-level permissions:, 1/10 had concurrency:, 0/10 had both. Now all ten have both. Every job that elevates (security-events: write, id-token: write, packages: write, contents: write) keeps its own block, which still overrides the top-level default.

cancel-in-progress is deliberately not true everywhere

The standard states the rule as cancel-in-progress: true, but applying that blanket-wise here would be actively harmful, and this repo already knew it — smoke-test.yml shipped with cancel-in-progress: false # Never cancel — would orphan cloud resources before this PR. That precedent generalizes:

Workflow	cancel	Why
ci, codeql, dependency-review	true	Pure recomputation on a superseded commit
smoke-test	false	Creates billable EC2 instances, key pairs, security groups, Hetzner servers + volumes; the remo … destroy steps run last, so a cancellation leaks them until the 4-hourly cleanup reaps them
provision / teardown	false	Half-provisioned infra, or a destroyed server with its volume still billing
smoke-test-cleanup	false	Its deletes run in sequence (instances → key pairs → security groups); a cancelled run leaves that half-applied. It does not create orphans — it is the reaper — but a scheduled run must not interrupt a manual one mid-delete
release	false	A cancelled publish desynchronizes tag / GitHub Release / PyPI / GHCR
release-please	false	Can leave the release PR half-amended
dev-build	false	Discards a wheel someone is waiting on

Verification

• uv run pytest — 2564 passed, 19 skipped
• uv run ruff check src/remo_cli — clean
• uv run mypy src/remo_cli — clean, 78 files
• All ten workflow files parse, with both keys present and every job-level elevation intact

Not in this PR

The rest of the standard is deliberately out of scope here: [dependency-groups], explicit ruff select, linting tests/, ruff format --check, pytest --strict-markers/--timeout/asyncio_mode, coverage floor, mypy strictness ratchet, requires-python ceiling, a task runner + check verb, hatch-vcs dynamic versioning, and reducing AGENTS.md to a pointer. Each needs a decision or a reformat commit; none is mechanical.

hatch-vcs in particular should be decided before or well after cutting 4.4.0, not during.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MzLwS8fijKdrVVh7oj9kNd