Introduce tiny Project issue size

[codeforester]

Problem

Base-managed GitHub Projects currently standardize Size as S, M, and L. S is doing double duty for both small implementation work and truly tiny administrative, documentation, or metadata changes. That makes backlog scanning less precise and gives AI-created issues no way to distinguish tiny scope from ordinary small scope.

Proposal

Introduce a new T size option meaning tiny, while keeping S as the default for new issues. T should be opt-in and narrowly defined: one obvious change, usually one file or one Project metadata action, with no design decision, cross-module behavior, or meaningful integration risk.

Scope

• Add T to the standardized Project Size options before S.
• Keep .github/base-project.yml and generated repo defaults at size: S.
• Update Project configuration/backfill workflows so repo Projects can create or preserve the new T option.
• Update docs that currently list Size: S, M, L to document T, S, M, L and define when each value should be used.
• Update AI/contributor workflow guidance so issue creators choose T, S, M, or L based on actual scope instead of always using the default.
• Keep automation-created issues defaulting to S when no explicit size is supplied.

Acceptance Criteria

• Base Project schema/configuration supports the T option without changing the default issue size from S.
• Repo baseline and GitHub workflow docs explain T clearly and keep Status, Priority, and Size standardized across repos.
• AI-facing guidance tells agents to choose the smallest accurate size for explicitly scoped issue creation, while using S when scope is not yet known.
• Existing workflows and tests that assume S, M, L are updated to include T where they validate or render allowed size options.
• Project field migration/backfill remains additive and does not overwrite existing item size values.