refactor: make objects set-access access a positional arg

[designcode]

Summary

Drop the --access flag in favor of a third positional. This makes the missing-required check actually exit 1 and lines the command up with how the rest of the objects subcommands work.

tigris objects set-access my-bucket my-file.txt public
tigris objects set-access t3://my-bucket/my-file.txt private

Why

The --access flag was declared required: true on a spec option. That routes through validateRequiredWhen in cli-core.ts, which prints the error to stderr but doesn't call process.exit(1) — Node defaults to exit 0. The CI integration test objects set-access > should error on missing --access failed for this reason after #100.

Every other "X is required" assertion in the integration suite (touch, cp, mv, etc.) succeeds because the required arg is a positional, and Commander's own missing-positional path exits with code 1. Following that pattern fixes the test naturally without touching cli-core.ts.

Changes

• specs.yaml — access moved from option-style (alias: a, required: true) to a third positional with options: *access_options for help text.
• src/lib/objects/set-access.ts — resolution mirrors objects put: if the first positional is a t3://bucket/key path, the second positional becomes the access value; otherwise the second is key and the third is access. Runtime checks for missing access and invalid value, both exiting 1 via failWithError.
• test/cli.test.ts — old --access public/private invocations switched to positional; added cases for the t3:// form, missing access (exit 1), and an invalid value (exit 1).

Test plan

• npm run lint, format:check, tsc --noEmit clean
• npm test — 659 unit/spec tests pass
• npm run build clean
• Local smoke: missing access → exit 1; invalid value → exit 1; bucket key public → 0; t3://bucket/key public → 0
• CI integration job runs the new positional invocations against a real bucket

🤖 Generated with Claude Code